Bug 46692 – REGRESSION (r61637): Lightbox resizes to incorrect size on octranspo1.com/routes

• Component: DOM
• Status: UNCONFIRMED

[Gilles Gauthier]

Overview: When clicking a lightbox on this website, it resizes to a smaller size than it should. 

Steps to Reproduce: 
1. Open http://www.octranspo1.com/routes/.
2. Click on the map on the right-hand side.

Actual Results: The lightbox expands to a smaller size than its defined size.

Expected Results: The lightbox should expand to its defined size.

Build Date & Platform: Safari 5.0.2 (6533.18.5) release build on Mac OS 10.6.4, and nightly build r68419, built on 27 September 2010.

Additional Builds and Platforms: The issue does not appear to occur on any other browser that I tested, or even on the same version of Safari on Windows. It appears to strictly occur on Mac OS X.

Additional Information: Issue may be a regression, as it seems to appear correctly on Safari 5.0.1, but not on 5.0.2, and also appears correctly on old nightly builds (tested on r60605, built on 3 June 2010).

[Alexey Proskuryakov]

I cannot reproduce this with Safari 5.0.2 on Mac OS X - the map seems to be the same (reasonable) size as in Firefox.

Could you please attach a screenshot? Do you happen to have any Safari extensions or hacks installed on the machine where you observe this problem?

[Gilles Gauthier]

Sorry. While I did have 2 other people test it prior to submitting, I should've thought to disable extensions. It appears that the problem does not occur if I disable a specific seemingly unrelated extension.

[Alexey Proskuryakov]

It's possible that this is a WebKit bug, although there is a chance of an extension bug, of course.

You can report this to the extension author or to us. If you'd like us to investigate, please do tell what the extension is (assuming it's publicly available).

[Gilles Gauthier]

The extension I was using and its source is here:
http://github.com/bdougherty/tynt-blocker

I tried similar extensions, and they caused the same issue.

[Alexey Proskuryakov]

Thanks!

CC'ing Andy and Oliver, who previously fixed some issue with such blocker extensions.

[Alexey Proskuryakov]

<rdar://problem/8890063>

[Andy Estes]

This is a regression caused by http://trac.webkit.org/changeset/61637. Needs a reduction, obviously.

[Adam Barth]

I can't reproduce this issue.  The lightbox expands beautifully using a WebKit nightly build and in the Chrome Dev channel.  Please re-open this bug if you can still reproduce the issue.

[Alexey Proskuryakov]

Adam, did you install tynt-blocker when trying to reproduce?

[Eric Seidel (no email)]

Does this count as returning false, thus preventing the load?
https://github.com/bdougherty/tynt-blocker/blob/master/tyntblock.js#L15

[Eric Seidel (no email)]

I did not test with tyntblocker, but I don't see how that could be related here. Tyntblocker doesn't use fragment parsing and the page doesn't reference "tynt" anywhere.

[Andy Estes]

I was able to reproduce this in January (with Safari extensions turned off), but I can't now.

[Alexey Proskuryakov]

> Does this count as returning false, thus preventing the load?

If it did, the extension wouldn't work at all, right?

> I did not test with tyntblocker, but I don't see how that could be related here.

A global onbeforeload handler changes a lot in how a page is loaded, see e.g. bug 45586.  For the reporter, this was only reproducible when any similar blocker extension was installed and enabled.

[Eric Seidel (no email)]

I confirm that with the extension installed the lightbox doesn't work right.

Why? Who knows.

[Eric Seidel (no email)]

I installed the extension from http://brad.is/software/TyntBlocker.safariextz (which may be different from the source on the github.

[Alexey Proskuryakov]

> Why? Who knows.

But this is still a regression from enabling HTML5 parser, right? Extensions are first class citizens, that's the whole point of their existence.

[Adam Barth]

@Eric: Can you look at this bug since you were able to reproduce it?

[Eric Seidel (no email)]

(In reply to comment #7)
> This is a regression caused by http://trac.webkit.org/changeset/61637. Needs a reduction, obviously.

@Andy: Did we do a build bisection or some other method to prove that it was that exact change?

[Eric Seidel (no email)]

As far as I can tell, this is using scriptaculous's lightwindow:
http://script.aculo.us/

Which is all being inserted into the page via:
http://www.octranspo1.com/cached_core.js

This is the code in question:

	<div class="calloutLight round5px"> 
		<h3>Quick Links</h3> 
		<a href="/index.php/routes/#routeImageLightwindow" class="lightwindow preview" title="Route Map for Route 001"><img src="http://www.octranspo1.com/images/files/routes/001map.gif" alt="Route Map" /></a> 
		<ul class="calloutFooterLinks"> 
			<li><a href="/index.php/routes/#routeImageLightwindow" class="lightwindow" title="Route Map for Route 001">View map</a></li> 
                        			<li><a href="http://www.octranspo1.com/images/files/route_pdf/map_carte_001.pdf" class="PDF">Print Map</a></li> 
                        			<li><a href="/route/printRoute?selectRoute=001&amp;year=2011&amp;month=05&amp;day=12&amp;from_site=yes" target="_blank" id="timetableLink">View timetable in text format</a></li> 
		</ul> 
	        <div id="routeImageLightwindow" style="display:none"><img src="http://www.octranspo1.com/images/files/routes/001map.gif" alt="Route Map" /></div> 
		<div class="clear"></div> 
	</div>

[Eric Seidel (no email)]

The page is XHTML, but it looks like they're sending it as text/html:

curl -I "http://www.octranspo1.com/routes/"                                                                                                                 [/Projects/WebKit]
HTTP/1.1 200 OK
Date: Thu, 12 May 2011 17:26:05 GMT
Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny10 with Suhosin-Patch
X-Powered-By: PHP/5.2.6-1+lenny10
Set-Cookie: exp_last_visit=989875565; expires=Fri, 11-May-2012 17:26:05 GMT; path=/
Set-Cookie: exp_last_activity=1305235565; expires=Fri, 11-May-2012 17:26:05 GMT; path=/
Set-Cookie: exp_tracker=a%3A1%3A%7Bi%3A0%3Bs%3A8%3A%22%2Froutes%2F%22%3B%7D; path=/
Set-Cookie: oclang=en; expires=Thu, 02-Jun-2011 17:26:05 GMT; path=/; domain=.octranspo1.com; httponly
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Thu, 12 May 2011 17:26:10 GMT
Pragma: no-cache
Vary: Accept-Encoding
Connection: close
Content-Type: text/html

[Eric Seidel (no email)]

The next step is to try modifying the extension (to see what exact behavior is causing this) but Safari won't let me do that because I don't have a Safari developer certificate.  I'm not interested in getting one.  Leaving this to Apple to solve.

[Eric Seidel (no email)]

This is the lightwindow.js source in question:
http://www.octranspo1.com/scripts/lightwindow.js

it's minified as part of:
http://www.octranspo1.com/cached_core.js

But I believe those two files to be the same version.

It's not clear how the HTML5 parser could affect this (if it is even?).  lightwindow is using innerHTML, but having a (theoretically) noop beforeunload handler could only be causing races?

Maybe the old parser didn't fire beforeunloads?

[Andy Estes]

(In reply to comment #18)
> (In reply to comment #7)
> > This is a regression caused by http://trac.webkit.org/changeset/61637. Needs a reduction, obviously.
> 
> @Andy: Did we do a build bisection or some other method to prove that it was that exact change?

I did a bisection in January which indicated r61637 was to blame, but when I looked a month later I was unable to reproduce the issue.