Closed
Bug 402007
Opened 17 years ago
Closed 17 years ago
Top border missing in gmail message view
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
INVALID
People
(Reporter: smontagu, Assigned: roc)
References
()
Details
(Keywords: regression, testcase)
Attachments
(4 files)
As of today I no longer see the border at the top of the message or messages in the gmail message view. I didn't see the same issue yesterday, but I do see it today in yesterday's build. In Firefox 2.0.0.8 everything is fine. I gather there was a gmail update in the last 24 hours, so this is a regression from some time in the past that the update is exposing.
Reporter | ||
Comment 1•17 years ago
|
||
Reporter | ||
Comment 2•17 years ago
|
||
Reporter | ||
Comment 3•17 years ago
|
||
I identified a regression date between 2006090909 and 2006091008 (using seamonkey builds from archive.mozilla.org) but there is more to this than meets the eye: gmail apparently redirects to different URIs depending on the build date. Before the regression date the URI is http://mail.google.com/mail/?ui=1, and if I load that URI manually it works even in builds after the regression date, up to and including current trunk. After the regression date the URI is http://mail.google.com/mail/?shva=1#inbox/... where ... is a 16-figure hex number. I tried loading that URI manually in builds before the regression date, but it just redirects back to http://mail.google.com/mail/?ui=1
Reporter | ||
Comment 4•17 years ago
|
||
The different URIs come from this javascript in the gmail page: var r=/webkit\/([^ ]+)/.exec(agt); var sup = (agt.indexOf("msie 7") != -1 && !masq) || agt.indexOf("firefox/1.5") != -1 || agt.indexOf("firefox/2.") != -1 || agt.indexOf("firefox/3") != -1 || (navigator.product == 'Gecko' && navigator.productSub > '20060909') || (r && r[1].split('.')[0] > 522); if (!sup) { location = "?ui=1"; } Using UA-spoofing I got a more accurate regression range: between 2006012409 and 200612609 (the build in between these two, 200612511, has XML errors on startup) 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=2006-01-24+09%3A00%3A00&maxdate=2006-01-26+09%3A00%3A00&cvsroot=%2Fcvsroot Maybe bug 317375?
Flags: blocking1.9?
Assignee | ||
Comment 6•17 years ago
|
||
I could probably fix this easily if I had a small testcase...
Comment 7•17 years ago
|
||
This seems to be wfm here on windows with today's trunk build.
Assignee | ||
Comment 8•17 years ago
|
||
Definitely not WFM with on Mac with today's build. Mac-only? (Martijn, I assume you verified you have the new GMail UI code)
Comment 9•17 years ago
|
||
Yes.
Reporter | ||
Comment 10•17 years ago
|
||
Not Mac-only: I reported it on Windows and I see it on Linux as well
OS: Windows XP → All
Hardware: PC → All
Comment 11•17 years ago
|
||
There should be a green bar covering most of the text. (The green bar is analogous to the top border in Gmail).
Comment 12•17 years ago
|
||
Simpler testcase. I'm not sure why (or whether) the previous ("PASS") behavior is more correct. Note that removing the "overflow:hidden" from the first div results in the new behavior ("FAIL") on pre-regression builds as well.
Assignee | ||
Comment 13•17 years ago
|
||
I think the new behaviour is correct according to http://www.w3.org/TR/CSS21/zindex.html which is pretty clear that "overflow" doesn't affect the z-ordering of anything. I'll contact my new friends in the GMail team.
Assignee | ||
Comment 14•17 years ago
|
||
Marking INVALID, in the absence of counter-arguments.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
Reporter | ||
Updated•15 years ago
|
Flags: blocking1.9?
You need to log in
before you can comment on or make changes to this bug.
Description
•