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).
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?
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.
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).
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.
Thanks! CC'ing Andy and Oliver, who previously fixed some issue with such blocker extensions.
<rdar://problem/8890063>
This is a regression caused by http://trac.webkit.org/changeset/61637. Needs a reduction, obviously.
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.
Adam, did you install tynt-blocker when trying to reproduce?
Does this count as returning false, thus preventing the load? https://github.com/bdougherty/tynt-blocker/blob/master/tyntblock.js#L15
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.
I was able to reproduce this in January (with Safari extensions turned off), but I can't now.
> 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.
I confirm that with the extension installed the lightbox doesn't work right. Why? Who knows.
I installed the extension from http://brad.is/software/TyntBlocker.safariextz (which may be different from the source on the github.
> 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.
@Eric: Can you look at this bug since you were able to reproduce it?
(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?
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&year=2011&month=05&day=12&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>
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
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.
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?
(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.