Bug 46692 - REGRESSION (r61637): Lightbox resizes to incorrect size on octranspo1.com/routes
Summary: REGRESSION (r61637): Lightbox resizes to incorrect size on octranspo1.com/routes
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.6
: P2 Normal
Assignee: Nobody
URL: http://www.octranspo1.com/routes/
Keywords: InRadar, NeedsReduction, Regression
Depends on: 40645
Blocks: 41115
  Show dependency treegraph
 
Reported: 2010-09-27 20:02 PDT by Gilles Gauthier
Modified: 2011-05-16 14:45 PDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gilles Gauthier 2010-09-27 20:02:39 PDT
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).
Comment 1 Alexey Proskuryakov 2010-09-27 23:19:58 PDT
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?
Comment 2 Gilles Gauthier 2010-09-28 18:50:55 PDT
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.
Comment 3 Alexey Proskuryakov 2010-09-28 19:54:41 PDT
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).
Comment 4 Gilles Gauthier 2010-09-28 20:01:17 PDT
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.
Comment 5 Alexey Proskuryakov 2010-09-28 20:11:18 PDT
Thanks!

CC'ing Andy and Oliver, who previously fixed some issue with such blocker extensions.
Comment 6 Alexey Proskuryakov 2011-01-19 17:47:36 PST
<rdar://problem/8890063>
Comment 7 Andy Estes 2011-01-19 19:07:37 PST
This is a regression caused by http://trac.webkit.org/changeset/61637. Needs a reduction, obviously.
Comment 8 Adam Barth 2011-02-16 01:15:19 PST
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.
Comment 9 Alexey Proskuryakov 2011-02-16 01:24:28 PST
Adam, did you install tynt-blocker when trying to reproduce?
Comment 10 Eric Seidel (no email) 2011-02-16 01:30:51 PST
Does this count as returning false, thus preventing the load?
https://github.com/bdougherty/tynt-blocker/blob/master/tyntblock.js#L15
Comment 11 Eric Seidel (no email) 2011-02-16 01:34:11 PST
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.
Comment 12 Andy Estes 2011-02-16 01:57:46 PST
I was able to reproduce this in January (with Safari extensions turned off), but I can't now.
Comment 13 Alexey Proskuryakov 2011-02-16 08:40:43 PST
> 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.
Comment 14 Eric Seidel (no email) 2011-02-16 12:43:40 PST
I confirm that with the extension installed the lightbox doesn't work right.

Why? Who knows.
Comment 15 Eric Seidel (no email) 2011-02-16 12:48:09 PST
I installed the extension from http://brad.is/software/TyntBlocker.safariextz (which may be different from the source on the github.
Comment 16 Alexey Proskuryakov 2011-03-14 14:56:52 PDT
> 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.
Comment 17 Adam Barth 2011-05-12 00:44:51 PDT
@Eric: Can you look at this bug since you were able to reproduce it?
Comment 18 Eric Seidel (no email) 2011-05-12 10:22:00 PDT
(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?
Comment 19 Eric Seidel (no email) 2011-05-12 10:25:15 PDT
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>
Comment 20 Eric Seidel (no email) 2011-05-12 10:26:44 PDT
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
Comment 21 Eric Seidel (no email) 2011-05-12 11:17:38 PDT
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.
Comment 22 Eric Seidel (no email) 2011-05-12 11:20:36 PDT
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?
Comment 23 Andy Estes 2011-05-16 14:45:47 PDT
(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.