79.55 KB, image/jpeg
38.32 KB, image/png
177 bytes, text/html
213 bytes, text/html
2.23 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050718 Camino/0.9a2 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050718 Camino/0.9a2 The left side oof Gmail webmail interface doesn't render correctly. The panel seems to bo too narrow and elements overlap the mail listing. Reproducible: Always Steps to Reproduce: 1. logon to your gmail account 2. switch language to polish if necessary 3. Expected Results: The page should render correctly, as in e.g. Firefox or Safari
WFM in English (although it has gotten narrower today), but nothing overlaps. Please attach a screenshot.
(In reply to comment #1) > WFM in English (although it has gotten narrower today), but nothing overlaps. By "gotten narrower today" I mean Gmail has made a change; a week-old DeerPark a2 build also displays that column narrower than it used to be yesterday.
A ha! One has to set one's Gmail prefs to Polish; the Gmail language setting is not determined from the browser's accept-lang headers. I can now reproduce this in Camino 20050720 and DeerPark a2. Safari 1.3 widens the column to prevent the overlap. This means it's either a Gecko bug, a Gmail bug (Gmail sends different content to different browsers), or a Gmail bug that is also a hole in Safari's standards compliance. Over to layout for further triage....
*** Bug 305365 has been marked as a duplicate of this bug. ***
Marking All/All since duplicate was on Windows. Adding regression keyword since this WFM on Firefox 1.0. The above duplicate contains "before" and "afetr" screenshots for Spanish.
In comment #7 I was referring to Firefox, of course. Using archived Camino builds, I narrowed the regression window to between 2004-10-11-08 and 2004-10-12-08. Checkins: http://tinyurl.com/bv8bd (there were quite a lot of them).
In trunk build, the div id="co" has a style="margin-left: 14ex;" But in Mozilla1.7, the div id="co" has a style="margin-left: 19ex;" So that explains the difference. Layout technically, Mozilla isn't doing anything wrong. Why this difference happens, I have no idea. Might be some browser detection issue from Gmail.
*** Bug 307596 has been marked as a duplicate of this bug. ***
*** Bug 307721 has been marked as a duplicate of this bug. ***
Created attachment 195486 [details] Also in phpbb forums redering fails I've just noticed that in phpbb forums the rendering fails too. IS not a google side problem.
*** Bug 307834 has been marked as a duplicate of this bug. ***
Created attachment 195523 [details] Testcase, part 1 This is part 1 of a testcase. I'll explain it when I post part 2.
Created attachment 195524 [details] Testcase, part 2 This part of the testcase is a frameset, where the upper frame is 100% height and blank, and the the bottom frame (which is of zero height) contains part 1 of the testcase. Part 1 simply pops up an alert with window.document.body.scrollWidth. When you load part 1 directly, the alert reports the actual window width. When you load part 2 (the frameset), the alert reports a width of 0. Before this regressed, you would get the same result when loading the testframe as when you loaded part 1 directly (i.e. the actual window width). Why this causes the Gmail bug: What Gmail does is to create spans (in the hidden "js" frame) containing the various labels of the "tabs" on the left ("Inbox", "Junk Mail", etc.), measure them (using scrollWidth), and decide on the width of the left column based on these measurements. What currently happens, is that these spans think they are contained in a zero-width body, and therefore wrap whenever possible (i.e. after each word). So the scrollWidth actually measures the width of the longest word in the label, rather than the width of the entire label. This makes the Gmail JS think that the minimum width (14ex) is sufficient to contain these labels, when it actually isn't.
Boris, David - could one of you please verify, based on the testcase and comment #17, that this is valid - and if it is, assign it to someone who's able to fix it? Thanks.
Comment on attachment 195486 [details] Also in phpbb forums redering fails This phpBB problem is totally unrelated (and WFM, BTW).
Nominating for blocking1.8b5 - Gmail is big enough to require this to be fixed, this way or another.
OK, this behavior changed between 2004-10-11-08 and 2004-10-12-07. Checkins in that range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-10-11+08%3A00%3A00&maxdate=2004-10-12+07%3A00%3A00&cvsroot=%2Fcvsroot I have no idea what in that range could be causing this, but the upshot is that there is no presshell in the subframe when the JS executes, so the sizes come back as 0.
This bug is one of those that shows up among the reports making mail.google.com a top50 site in Reporter.
If anyone can narrow down which checkin caused this, that would help a great deal...
Tracy, can you help us figure out when this regressed?
(In reply to comment #24) > Tracy, can you help us figure out when this regressed? See comment #8 and comment #21.
Note comment 23: someone needs to start binary-searching within that day, or backing out patches, or something... :(
Zinging your way bz - can you help us drive this to closure?
Not in time for 1.8b5 -- I'll need a solid chunk of 3-4 hours consecutive free time to even hunt down which fix caused the problem, before I can start fixing anything, and I won't have such until next Thursday at least. If someone else sorts out which checkin is responsible, that would help a lot here.
roc, I decided that bug 238493 was the most likely culprit, and indeed after backing it out locally this bug went away. What I don't see is WHY that patch would cause this. The only difference between a working and non-working build is that the scrolled view is 0x0 sized in the non-working build. The scrollport (outer) view is 0x0 in both...
Note that I tried the obvious things, like taking out the early returns in nsView::ResetWidgetBounds and commenting out all view update batching in the presshell. Neither helped.
So the difference seems to be that when we call mWindow->GetBounds in DocumentViewerImpl::InitPresentationStuff we end up with a width of 0 in broken builds and a nonzero width (albeit a zero height) in non-broken ones. Then we proceed to reflow everything with an avail width of 0, with the obvious consequences.
Created attachment 197807 [details] [diff] [review] OK, this fixes it... The nsView change is enough, but the nsViewManager change seemed like the right thing to do.... We were setting a new size that was X by 0 instead of 0 by 0, and the view was just ignoring it completely, so the widget size never changed, so we never got the right width for the InitialReflow...
12 years ago
The other option might be to change the document viewer to get its size from the docshell's nsIBaseWindow interface (in pixels) instead of using the widget's bounds.... I can try that if you prefer, roc.
Comment on attachment 197807 [details] [diff] [review] OK, this fixes it... this is good enough
Comment on attachment 197807 [details] [diff] [review] OK, this fixes it... Let's get this landed trunk and branch ASAP (time's too short for this to spend significant time baking on the trunk).
Fixed, trunk and branch. We'll end up doing the docshell thing when we remove widgets, I guess.
Verified with Windows and Linux Fx 1.4 builds and Mac Deer PArk trunk builds from 0930 using Polish test case
I dont know how to do a test case or what, but now it works. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050930 Firefox/1.6a1 Windows XP Professional Compilation Version 2600.xpsp_sp2_gdr.050301-1519 (Service Pack 2)
The nsView part of this patch is causing OS/2 builds to hang on initial resize. Any ideas why?
The nsView part is the part really really needed to fix this bug, fwiw. I can see it causing problems if for some reason we end up in a recursive stack with slightly different values coming through every time. Can you break when it hangs and see what the stack looks like?
12 years ago