402007 - Top border missing in gmail message view

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Simon Montagu :smontagu]

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.

Comment 1

[Simon Montagu :smontagu]

Attachment: Trunk screenshot

Comment 2

[Simon Montagu :smontagu]

Attachment: 2.0.0.8 screenshot

Comment 3

[Simon Montagu :smontagu]

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

Comment 4

[Simon Montagu :smontagu]

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?

Comment 5

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

Quite possibly.

Comment 6

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

I could probably fix this easily if I had a small testcase...

Comment 7

[Martijn Wargers (dead)]

This seems to be wfm here on windows with today's trunk build.

Comment 8

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

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

[Martijn Wargers (dead)]

Yes.

Comment 10

[Simon Montagu :smontagu]

Not Mac-only: I reported it on Windows and I see it on Linux as well

Comment 11

[Uri Bernstein]

Attachment: testcase

There should be a green bar covering most of the text. (The green bar is analogous to the top border in Gmail).

Comment 12

[Uri Bernstein]

Attachment: testcase #2

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.

Comment 13

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

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.

Comment 14

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

Marking INVALID, in the absence of counter-arguments.