301411 - [FIX]left side of Gmail web interface doesn't render correctly in some languages

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Radek Jurzysta]

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

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

WFM in English (although it has gotten narrower today), but nothing overlaps.

Please attach a screenshot.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(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.

Comment 3

[Radek Jurzysta]

Attachment: screenshot made on Gmail webmail.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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....

Comment 5

[Uri Bernstein]

*** Bug 305365 has been marked as a duplicate of this bug. ***

Comment 6

[Uri Bernstein]

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.

Comment 7

[Uri Bernstein]

Hmmm...
The apparent regression occured between 2004-10-10 and 2004-10-29. This is a
large window, since I can't find any builds between these dates in the archives.

It's difficult to create a minimal testcase here, because the rendered HTML
(what you see when you do "view selection source") is already different between
the "good" and "broken" versions, e.g.:

<div style="position: absolute; left: 1ex; width: 19ex;" id="nav">
vs.
<div style="position: absolute; left: 1ex; width: 14ex;" id="nav">

So initially I thought Google was just sending different HTML to different
Firefox builds. But this is unlikely, since the working and broken builds from
October 2004 have the same User-Agent string (except for the build date, of course).

So I'm assuming that the HTML is somehow built dynamically, and for whatever
reason it is built differently on the old and newer builds. However, Google's
javascript is not easy to understand.

Comment 8

[Uri Bernstein]

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).

Comment 9

[Uri Bernstein]

CC'ing Marcia to make sure sure this gets some QA attention.

This is a very tricky bug since I can't make a reduced testcase, and it's not
even clear what component it is in (could be anything from layout to javascript
to tech evangelism).

Comment 10

[Martijn Wargers (dead)]

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.

Comment 11

[Phil Ringnalda (:philor)]

*** Bug 307596 has been marked as a duplicate of this bug. ***

Comment 12

[Frank Wein [:mcsmurf]]

*** Bug 307721 has been marked as a duplicate of this bug. ***

Comment 13

[Rubén Martín [:Nukeador] ❌ [away till Aug 31st]]

Attachment: BAd rendering with spanish gmail too

Comment 14

[Rubén Martín [:Nukeador] ❌ [away till Aug 31st]]

Attachment: Also in phpbb forums redering fails

I've just noticed that in phpbb forums the rendering fails too. IS not a google
side problem.

Comment 15

[Phil Ringnalda (:philor)]

*** Bug 307834 has been marked as a duplicate of this bug. ***

Comment 16

[Uri Bernstein]

Attachment: Testcase, part 1

This is part 1 of a testcase. I'll explain it when I post part 2.

Comment 17

[Uri Bernstein]

Attachment: 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.

Comment 18

[Uri Bernstein]

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 19

[Uri Bernstein]

Comment on attachment 195486 [details]
Also in phpbb forums redering fails

This phpBB problem is totally unrelated (and WFM, BTW).

Comment 20

[Uri Bernstein]

Nominating for blocking1.8b5 - Gmail is big enough to require this to be fixed,
this way or another.

Comment 21

[Boris Zbarsky [:bzbarsky]]

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.

Comment 22

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This bug is one of those that shows up among the reports making mail.google.com
a top50 site in Reporter.

Comment 23

[Boris Zbarsky [:bzbarsky]]

If anyone can narrow down which checkin caused this, that would help a great deal...

Comment 24

[Asa Dotzler [:asa]]

Tracy, can you help us figure out when this regressed?

Comment 25

[Uri Bernstein]

(In reply to comment #24)
> Tracy, can you help us figure out when this regressed?

See comment #8 and comment #21.

Comment 26

[Boris Zbarsky [:bzbarsky]]

Note comment 23: someone needs to start binary-searching within that day, or
backing out patches, or something... :(

Comment 27

[Mike Schroepfer]

Zinging your way bz - can you help us drive this to closure?

Comment 28

[Boris Zbarsky [:bzbarsky]]

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.

Comment 29

[Boris Zbarsky [:bzbarsky]]

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...

Comment 30

[Boris Zbarsky [:bzbarsky]]

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.

Comment 31

[Boris Zbarsky [:bzbarsky]]

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.

Comment 32

[Boris Zbarsky [:bzbarsky]]

Attachment: 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...

Comment 33

[Boris Zbarsky [:bzbarsky]]

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 34

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 197807 [details] [diff] [review]
OK, this fixes it...

this is good enough

Comment 35

[Asa Dotzler [:asa]]

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).

Comment 36

[Boris Zbarsky [:bzbarsky]]

Fixed, trunk and branch.  We'll end up doing the docshell thing when we remove
widgets, I guess.

Comment 37

[Tracy Walker [:tracy]]

Verified with Windows and Linux Fx 1.4 builds and Mac Deer PArk trunk builds
from 0930 using Polish test case

Comment 38

[Luis Lobo Borobia]

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)

Comment 39

[Mike Kaply [:mkaply]]

The nsView part of this patch is causing OS/2 builds to hang on initial resize.
Any ideas why?

Comment 40

[Boris Zbarsky [:bzbarsky]]

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?

Comment 41

[Andrew Schultz]

this caused bug 311223 (there are some stacks there)