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

VERIFIED FIXED in mozilla1.8beta5

Status

()

Core
Layout
P2
normal
VERIFIED FIXED
13 years ago
6 years ago

People

(Reporter: Radek Jurzysta, Assigned: bz)

Tracking

(Depends on: 1 bug, 4 keywords)

Trunk
mozilla1.8beta5
regression, testcase, top50, verified1.8
Points:
---
Bug Flags:
blocking1.8b5 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

13 years ago
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.
(Reporter)

Comment 3

13 years ago
Created attachment 190006 [details]
screenshot made on Gmail webmail.
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....
Assignee: pinkerton → nobody
Status: UNCONFIRMED → NEW
Component: Page Layout → Layout
Ever confirmed: true
Product: Camino → Core
QA Contact: layout
Version: unspecified → Trunk
*** 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.
Keywords: regression
OS: MacOS X → All
Hardware: Macintosh → All
Summary: left side of Gmail web interface doesn't render correctly → left side of Gmail web interface doesn't render correctly in some languages
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.
Keywords: qawanted
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).
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).
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 195417 [details]
BAd rendering with spanish gmail too
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. ***

Updated

12 years ago
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.
Keywords: qawanted → testcase
Comment on attachment 195486 [details]
Also in phpbb forums redering fails

This phpBB problem is totally unrelated (and WFM, BTW).
Attachment #195486 - Attachment is obsolete: true
Nominating for blocking1.8b5 - Gmail is big enough to require this to be fixed,
this way or another.
Flags: blocking1.8b5?
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.
Keywords: top50
If anyone can narrow down which checkin caused this, that would help a great deal...

Updated

12 years ago
Flags: blocking1.8b5? → blocking1.8b5+

Comment 24

12 years ago
Tracy, can you help us figure out when this regressed?
Keywords: qawanted
(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... :(

Comment 27

12 years ago
Zinging your way bz - can you help us drive this to closure?
Assignee: nobody → 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.
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...
Attachment #197807 - Flags: superreview?(roc)
Attachment #197807 - Flags: review?(roc)
Attachment #197807 - Flags: approval-l10n?
Priority: -- → P2
Summary: left side of Gmail web interface doesn't render correctly in some languages → [FIX]left side of Gmail web interface doesn't render correctly in some languages
Target Milestone: --- → mozilla1.8beta5
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
Attachment #197807 - Flags: superreview?(roc)
Attachment #197807 - Flags: superreview+
Attachment #197807 - Flags: review?(roc)
Attachment #197807 - Flags: review+

Comment 35

12 years ago
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).
Attachment #197807 - Flags: approval-l10n? → approval1.8b5+
Fixed, trunk and branch.  We'll end up doing the docshell thing when we remove
widgets, I guess.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
Verified with Windows and Linux Fx 1.4 builds and Mac Deer PArk trunk builds
from 0930 using Polish test case
Status: RESOLVED → VERIFIED
Keywords: fixed1.8, qawanted → verified1.8

Comment 38

12 years ago
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

12 years ago
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?

Comment 41

12 years ago
this caused bug 311223 (there are some stacks there)
Blocks: 311223
No longer blocks: 311223
Depends on: 311223

Updated

12 years ago
Blocks: 310854
No longer blocks: 310854
You need to log in before you can comment on or make changes to this bug.