XF 1.1 Lightbox behaviour

MattW · Jan 26, 2013

A few of my members with slower internet connections are having problems with viewing larger images in the lightbox popup.

Example post:
Contains 18 images, total size 58.1MB

Looking at what it's doing using Chrome, when you load lightbox from the first image, it's actually downloading ALL the full images at once to generate the main image, plus the thumbnails used to scroll through.

Then, when you click onto the next image, it's downloading the file twice, for what I can only assume is to load the main image, and the thumbnail again.

This is from me scrolling through the next 2 pictures

So viewing those 18 images in sequence in lightbox actually ends up using 180MB of bandwidth

Has anyone else notices this? I hadn't really noticed it on my fast connection, but people on less than 10MB connections are starting to pick up on it.

cclaerhout · Jan 26, 2013

Do you have the same problem with Firefox?
If no, it looks a common problem to http://xenforo.com/community/threads/style-properties-loads-slow.41475/#post-450382
and to http://xenforo.com/community/threads/cant-reply-in-some-threads.41883/

Which seems to be cause by a problem with the relative path with JS
http://xenforo.com/community/threads/change-to-absolute-urls.42721/

MattW · Jan 26, 2013

Haven't tried with Firefox. Will install and test now

MattW · Jan 26, 2013

Have tried with Firefox, and it's working as expected. It initially loads all the images, and then loads each image individually (only once) as you scroll through the images. You can then move back and forward between the ones already viewed without them being re-downloaded each time.

cclaerhout · Jan 26, 2013

So you arrived at the same conclusion that I have when I've checked the problem when loading style properties in chrome. I haven't try yet to configure JavaScript using the full path.

This is clearly the most major problem of XenForo right now. I don't know after which update of chrome it happened.

MattW · Jan 26, 2013

Yes, it's only when using Chrome. I also had a look at the other links and get the same behavior in the ACP as described.

This could become a problem as Chrome is now the most used browser on our site

cclaerhout · Jan 26, 2013

MattW said:
Yes, it's only when using Chrome. I also had a look at the other links and get the same behavior in the ACP as described.

This could become a problem as Chrome is now the most used browser on our site
View attachment 39777

Can you please try this fix : http://xenforo.com/community/threads/accidental-ajax-variable-injection.43782/
And confirm if the problem is fixed after? Thanks !

Jake Bunce · Jan 27, 2013

cclaerhout said:
So you arrived at the same conclusion that I have when I've checked the problem when loading style properties in chrome. I haven't try yet to configure JavaScript using the full path.

Use this report for that specific issue:

http://xenforo.com/community/threads/chrome-10-second-js-lag-on-loading-style-property-group.43808/

MattW · Jan 27, 2013

cclaerhout said:
Can you please try this fix : http://xenforo.com/community/threads/accidental-ajax-variable-injection.43782/
And confirm if the problem is fixed after? Thanks !

Not sure where to add that fix

This is the console output

I've had a look at the html output when lightbox is in use. The thumbnails are actually the smaller thumbnail images:

However, it's loading the FULL main image twice:

The second img id="LbImg" looks to be getting downloaded and loaded, but isn't visible.

cclaerhout · Jan 27, 2013

No sorry I don't think this this fix will solve your problem. I haven't tested the bug you describe but its behaviour looks like the one Jake opened a new thread for (see above).

Jake Bunce · Jan 28, 2013

In my testing both Chrome and Firefox appear to have the same behavior. They preload all full-sized images shown in the lightbox. When clicking through the images I get 304 responses for each request, the images having already been downloaded. This behavior is as expected, though the argument can be made for a configurable option to disable the precaching.

You say your browser is redownloading the full images as you navigation through the lightbox? Are you sure? It's not a 304?

MattW · Jan 28, 2013

Jake Bunce said:
You say your browser is redownloading the full images as you navigation through the lightbox? Are you sure? It's not a 304?

Yes, I'm getting a 200 response.

These are the access logs from just now as I browse through the images in that same thread in lightbox:

Code:

root@vps [~]# tail -f /usr/local/apache/logs/access_log | grep 195.188.150.130
195.188.150.130 - - [28/Jan/2013:07:09:23 +0000] "GET /forum/attachments/2012-10-13-11-17-11-jpg.8942/ HTTP/1.1" 200 2660829
195.188.150.130 - - [28/Jan/2013:07:09:24 +0000] "GET /forum/attachments/2012-10-13-10-42-42-jpg.8941/ HTTP/1.1" 200 3106903
195.188.150.130 - - [28/Jan/2013:07:09:24 +0000] "GET /forum/attachments/2012-10-13-11-17-11-jpg.8942/ HTTP/1.1" 200 2660829
195.188.150.130 - - [28/Jan/2013:07:09:40 +0000] "GET /forum/attachments/2012-10-13-11-17-11-jpg.8942/ HTTP/1.1" 200 2660829
195.188.150.130 - - [28/Jan/2013:07:09:40 +0000] "GET /forum/attachments/2012-09-19-09-50-17-jpg.8943/ HTTP/1.1" 200 3770537
195.188.150.130 - - [28/Jan/2013:07:09:42 +0000] "GET /forum/attachments/2012-10-13-11-17-11-jpg.8942/ HTTP/1.1" 200 2660829
195.188.150.130 - - [28/Jan/2013:07:09:41 +0000] "GET /forum/attachments/2012-09-19-09-50-17-jpg.8943/ HTTP/1.1" 200 3770537
195.188.150.130 - - [28/Jan/2013:07:09:42 +0000] "GET /forum/attachments/2012-10-13-11-17-11-jpg.8942/ HTTP/1.1" 200 2660829
195.188.150.130 - - [28/Jan/2013:07:09:42 +0000] "GET /forum/attachments/2012-09-19-09-50-17-jpg.8943/ HTTP/1.1" 200 3770537
195.188.150.130 - - [28/Jan/2013:07:09:43 +0000] "GET /forum/attachments/2012-09-19-09-50-17-jpg.8943/ HTTP/1.1" 200 3770537
195.188.150.130 - - [28/Jan/2013:07:09:48 +0000] "GET /forum/attachments/2012-09-19-09-50-24-jpg.8944/ HTTP/1.1" 200 3282346
195.188.150.130 - - [28/Jan/2013:07:09:48 +0000] "GET /forum/attachments/2012-09-19-09-50-17-jpg.8943/ HTTP/1.1" 200 3770537
195.188.150.130 - - [28/Jan/2013:07:09:49 +0000] "GET /forum/attachments/2012-09-19-09-50-24-jpg.8944/ HTTP/1.1" 200 3282346
195.188.150.130 - - [28/Jan/2013:07:09:49 +0000] "GET /forum/attachments/2012-09-19-09-50-17-jpg.8943/ HTTP/1.1" 200 3770537
195.188.150.130 - - [28/Jan/2013:07:09:50 +0000] "GET /forum/attachments/2012-09-19-09-50-24-jpg.8944/ HTTP/1.1" 200 3282346
195.188.150.130 - - [28/Jan/2013:07:09:50 +0000] "GET /forum/attachments/2012-09-19-09-50-24-jpg.8944/ HTTP/1.1" 200 3282346

Jake Bunce · Jan 28, 2013

Maybe it's a problem with the server vars. This is the relevant code:

XenForo_ControllerPublic_Attachment

Code:

		$eTag = $this->_request->getServer('HTTP_IF_NONE_MATCH');
		if ($eTag && $eTag == $attachment['attach_date'])
		{
			$this->_routeMatch->setResponseType('raw');
			return $this->responseView('XenForo_ViewPublic_Attachment_View304');
		}

If you would like I can debug this if you give me access.

MattW · Jan 29, 2013

Sure, what access do you require Jake?

Jake Bunce · Jan 29, 2013

Admin access, and maybe FTP.

MattW · Jan 30, 2013

Jake Bunce said:
Admin access, and maybe FTP.

Will drop you a PM with the details.

MattW · Feb 4, 2013

I'd like to thank Jake for his help in getting to the bottom of this.

For clarification, the issue was on my end, and not a problem with Lightbox or XenForo.

Jake spent some time debug'ing the response headers:

Jake Bunce said:

Ok. Here are the request/response headers from your attachment:

Code:

Request URL:http://www.z22se.co.uk/forum/attachments/2012-09-19-09-50-24-jpg.8944/
Request Method:GET
Status Code:200 OK
 
Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:<removed>
Host:www.z22se.co.uk
Referer:http://www.z22se.co.uk/forum/threads/engine-will-not-start-after-rebuild.21863/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17
 
Response Headers
Cache-control:private, no-cache, no-store, proxy-revalidate, no-transform
Connection:Keep-Alive
Content-Disposition:inline; filename="2012-09-19 09.50.24.jpg"
Content-Encoding:gzip
Content-Type:image/jpeg
Date:Sun, 03 Feb 2013 23:54:12 GMT
Etag:1352049415
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive:timeout=5, max=100
Last-Modified:Sun, 03 Feb 2013 23:54:12 GMT
Pragma:no-cache
Server:Apache
Transfer-Encoding:chunked
Vary:Accept-Encoding,User-Agent
X-Content-Type-Options:nosniff
X-Powered-By:PHP/5.4.11

Here are the headers for an attachment on my test forum:

Code:

Request URL:http://<mytestsite>/attachments/dunmorogh_ridgecamp-png.28/
Request Method:GET
Status Code:304 Not Modified
 
Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Authorization:<removed>
Cache-Control:max-age=0
Connection:keep-alive
Cookie:<removed>
Host:<mytestsite>
If-Modified-Since:Sun, 03 Feb 2013 01:26:51 GMT
If-None-Match:1359247650
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17
 
Response Headers
Cache-control:private, max-age=0
Connection:Keep-Alive
Date:Sun, 03 Feb 2013 23:58:12 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive:timeout=5, max=150
Server:Apache

You can see that "If-None-Match" is not being submitted when I request your attachment, but it is being submitted for my attachment. That is the nature of the problem. The question becomes why is it missing from the request? I believe it is related to these response headers from your forum:

Code:

Cache-control:private, no-cache, no-store, proxy-revalidate, no-transform
Pragma:no-cache

That would instruct my browser to not cache the resource.

I can't find where this response header is coming from. Perhaps something from your Apache config?

This was actually something that I had set in my .htaccess file, from a "guide" I followed from a resource on the shop software forum I also use, and had been there since 2010!

Code:

# Force no caching for dynamic files
<FilesMatch "\.(php|cgi|pl|htm)$">
ExpiresActive Off
Header set Cache-Control "private, no-cache, no-store, proxy-revalidate, no-transform"
Header set Pragma "no-cache"
</FilesMatch>

I've removed that, and it's working as expected again.

Rich (BB code):

Request URL:http://www.z22se.co.uk/forum/attachments/2012-09-19-09-50-24-jpg.8944/
Request Method:GET
Status Code:304 Not Modified
 
Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en,en-GB;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:<removed>
Host:www.z22se.co.uk
If-Modified-Since:Mon, 04 Feb 2013 00:38:41 GMT
If-None-Match:1352049415
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17
 
Response Headers
Cache-control:private, max-age=0
Connection:Keep-Alive
Date:Mon, 04 Feb 2013 06:25:33 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive:timeout=5, max=100
Server:Apache
Vary:Accept-Encoding,User-Agent

XF 1.1 Lightbox behaviour

MattW

Well-known member

cclaerhout

Well-known member

MattW

Well-known member

MattW

Well-known member

cclaerhout

Well-known member

MattW

Well-known member

cclaerhout

Well-known member

Jake Bunce

Well-known member

MattW

Well-known member

cclaerhout

Well-known member

Jake Bunce

Well-known member

MattW

Well-known member

Jake Bunce

Well-known member

MattW

Well-known member

Jake Bunce

Well-known member

MattW

Well-known member

MattW

Well-known member

Similar threads

We value your privacy