Closed Bug 415252 Opened 16 years ago Closed 16 years ago

gmail (new version) doesn't show names in contacts list

Categories

(Tech Evangelism Graveyard :: English US, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jst, Unassigned)

References

()

Details

(Keywords: regression, relnote)

Attachments

(2 files)

Looking at your contacts in gmail (the new version, which can be selected once you log in), you'll see a 3-column view, the left most column has "All Contacts", "Most Wanted", etc, clicking on those brings up a list in the middle column with the names of the contacts in that group, with a checkbox next to each name. The checkbox shows up, but there's no name next to it when using Firefox 3.

No errors on the JS console. Using the DOM inspector you can see that the name is there' but it looks like it starts behind the checkbox, and something is obscuring it (it's actually displayed after you click on the DOM text node in the DOM inspector, but it's on on top of the check box instead of next to it). Assigning to layout.
Flags: blocking1.9+
So the problem is that the markup looks like this:

<div class="row"
  ><div class="check"><input type="checkbox"
    ></div><div class="text">Text here</div></div>

(weird indent because there should be no whitespace anywhere here), with the following styles (the ones I think irrelevant trimmed):

.row { overflow: hidden; height: 1.5em; white-space: nowrap; }
.check { float: left; }
.text { width: 100%; overflow: hidden; }

Because .text has "overflow:hidden", it can't overlap the float.  But its width is explicitly 100%, so it can't fit next to the float either, and gets wrapped to the next line.  But then it overflows the fixed-height row, and the "overflow:hidden" on the row makes it invisible.  Simply setting "width: auto" on the .text div fixes things to work "right".

So as far as I can tell, given the styles the page is using our rendering is correct.  I'm not sure why I get a different rendering in Safari, to be honest.  But if I save as web page, complete in Firefox, I get very different behavior loading it in Firefox and Safari (Safari can't even load the page), so I wouldn't be all that surprised if the markup is different...
Note also bug 414558.
Summary: gmal (new version) doesn't show names in contacts list → gmail (new version) doesn't show names in contacts list
Regression range:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008012804 Minefield/3.0b3pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008012904 Minefield/3.0b3pre

Bonsai link:  http://tinyurl.com/3ex7jw
Version: unspecified → Trunk
Bonsai link, specific to "layout" directory: http://tinyurl.com/2jht53

Which possibly points to the checkin for bug 134706 / 349255...?  None of the other checkins seem related, at first glance.
Priority: -- → P1
Target Milestone: mozilla1.9beta4 → mozilla1.9beta3
> Which possibly points to the checkin for bug 134706 / 349255

That's exactly it, yes.

What we used to do here is to put the overflow:hidden text next to the float, even though it doesn't actually fit there, so it would stick out on the right.  In this case that wasn't visible, since overflow is hidden.

Now we push it to the next line, which is the right thing to be doing given this markup.

Oh, and the ancestor here has a fixed width, by the way.  So there is no intrinsic width stuff here to confuse things; all the width computations are very clear.

It sounds to me like we should report this to Google for a fix on their end...
So, I'd really like this fix to stick.  I think Web browsers converging is generally a good thing -- it gives developers fewer browser differences to deal with.  And in this case I think the IE behavior is better -- placing things where they fit rather than making them overlap/overflow is a good thing.

There are differences in intrinsic width behavior that counteract this for IE in some cases (and I hope IE converges on the intrinsic width behavior we now share with Opera and Safari).  That's the case for bug 414558, although it doesn't look like it's the case here based on what Boris wrote above (although it might be if the whole thing is inside something that shrink-wraps).  Safari has a quirk in intrinsic width calculation to fix bug 134706 / bug 349255 for only one of the most common cases by producing a wider intrinsic preferred width in one of the common cases where it matters for this -- essentially, something they had to do because (old) Gecko and IE did intrinsic width calculation by layout.  The patch I put in bug 414558 imitates that, but it's not sufficient to fix the testcase there because it seems gmail really depended on bug 134706 (maybe they send different content to IE?).  Though I'm not really sure when some of these simplified testcases are too simplified...
So the DOM I'm seeing on gmail for this bug looks somewhat like this:

body
 div
  table
   tbody
    tr
     td
      table
       tbody
        tr
         td
          table
           tbody
            tr
             td
              div class="checkable-list" style="width: 216px"
               div
                div class="row"
                 div class="check"
                 div class="text"

We lay out the <div class="row"> with a width of 216px, as expected.  I don't know where that width style comes from, but it's certainly wide enough to fit things if the <div class="text"> didn't have the 100% width style on it.

I'm sure the tables are doing shrink-wrapping, but that doesn't affect the sizing of the checkable-list and the things inside it, at least not once that width style is set.
Opera 9.5 has this issue too (Opera bug 294911). According to my contact from the Gmail team, a fix has already been checked in (I'm not sure if the fix targets Opera specifically or all browsers). It's apparently not live yet, though.
Target Milestone: mozilla1.9beta3 → mozilla1.9beta4
please relnote this for beta 3.  
Keywords: relnote
more than likly if opera has the issue it's Gmail that needs to fix it
The consensus is that our behaviour is desired and we want GMail to fix this, so, WONTFIX.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
If the decision is WONTFIX, has someone been in contact with the Gmail team yet to work on this?
(In reply to comment #17)
> If the decision is WONTFIX, has someone been in contact with the Gmail team yet
> to work on this?
> 

See comment #8 :-)
(In reply to comment #18)
> (In reply to comment #17)
> > If the decision is WONTFIX, has someone been in contact with the Gmail team yet
> > to work on this?
> > 
> 
> See comment #8 :-)
> 
Yes.
Thanks. relnote for beta 4, please
I would likely have caught this if the status wasn't WONTFIX since the search on https://bugzilla.mozilla.org/ by default only catches "active" bugs. 

Since this IS a problem, perhaps it would be more appropriate to be labeled as a TECH EVANGELISM bug?
Yeah, morphing this into a TE bug and closing it when gmail's live version is fixed seems better. There's no complaint in the summary or comment 0 to which WONTFIX is the desired response. The details found where IE and Safari cope are not part of the bug's original problem statement. I'll leave it to someone who is persuaded to do the deed, but this bug really should be open and filed against gmail, IMHO.

/be
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Assignee: nobody → english-us
Status: REOPENED → NEW
Component: Layout → English US
Flags: tracking1.9+
Product: Core → Tech Evangelism
QA Contact: layout → english-us
Target Milestone: mozilla1.9beta4 → ---
Version: Trunk → unspecified
I consider this a major problem - as it makes contact lookups in gmail difficult.  I am not sure what progress is on fixing this, but noticed it wasn't fixed in the latest release
This is an evangelism bug, here only to track the sites progress. We won't fix this for Firefox 3, we're working with the Gmail people to fix their code not to rely on old broken code.
(In reply to comment #34)
> I consider this a major problem - as it makes contact lookups in gmail
> difficult.  I am not sure what progress is on fixing this, but noticed it
> wasn't fixed in the latest release
> 

Google has fix and is in the process of getting it rolled out.  Should be done well in advance of FF3 ship.
It looks like Google rolled out the fix. I can see the contact list now. Can anyone confirm?
(In reply to comment #39)
> It looks like Google rolled out the fix. I can see the contact list now. Can
> anyone confirm?
> 

Confirmed with FF 3 Beta 4 on W2K.
Confirmed with FF3 Beta 4 on Vista and Linux. -> RESOLVED FIXED.
Status: NEW → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → FIXED
Confirmed with:
Build identifier: Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.9pre) Gecko/2008032904 Firefox/3.0
works
Status: RESOLVED → VERIFIED
Beta 5 is out, and this bug is being mentioned in its release notes page: <http://www.mozilla.com/en-US/firefox/3.0b5/releasenotes/>.  Maybe it should be better to remove it?
It's not fixed in Beta 5.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5

i see this fixed on the latest nightly.   Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040204 Minefield/3.0pre

Jonathan, can you try a nightly and see if its working for you?
Nope, still white here! :(

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040204 Minefield/3.0pre
Well, it's working ok for me even with beta 4 - the fix was on Google's side, so it shouldn't matter what Firefox build is used.  Google's servers often don't serve the same version to everyone simultaneously.  Are you using the american english language setting Jonathan?
Affirmative! Please let me know anything I can try to do to help you narrow it down.
Well, the fix is in Gmail, not in Firefox, so not much point in us trying to narrow it here.  I guess the thing to do is wait a week or so and see if the fix spreads around...
Hi guys, just another affirmative confirmation of the fix. I'll try the Spanish version of Gmail and will let you know.
  Daniel.
Works on beta5 and beta4.

Gmail has removed the width:100% from the div class="text"
(In reply to comment #47)
> Nope, still white here! :(
> 
> Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre)
> Gecko/2008040204 Minefield/3.0pre
> 

Wondering if Gmail team is rolling out their fixes by the farms, and your account isnt on that fixed cluster yet.  give it a few days, and report back here if you want.
Verified that it is fixed for me and got word that Google has pushed this fix to production...
Still not fixed in GMail for google apps... url is  https://mail.google.com/a
At least from Spain, my GMail for google apps is fixed too.
(In reply to comment #57)
> At least from Spain, my GMail for google apps is fixed too.
> 

Yes, this is working on my Google Apps now too.  I connect to google apps using https from the use https://mail.google.com/a.
Fixed here too, normal Gmail
its ok. finaly :D
thanks and to the firefox 4 
It's ok in the gmail with English language. Nothing chat if I choose Italian or other language. 
FF3b5 on Slackware Linux
Conraid:

I think you're talking about the quick-contacts *sidebar*, whereas this bug was about the contacts *page* (as in screenshot attachment 303367 [details]).

For the issue you're describing ("Nothing chat if I choose Italian or other language."), that's a known issue with "Gmail Older Version".  

There's no such issue in Gmail Newer Version, though, which Gmail defaults to in English, and will soon be defaulting to in other languages as well.  For more information / any comments on this, see bug 407257 (in particular bug 407257 comment 29).
Gmail chat with FF2 is ok, with FF3beta no.
Now I read the bug 407257, thanks 
For me it only works when I have English (US) set as my language in GMail. Not sure if it is only fixed for English (US) at google, or if it has something to do with the Gmail-language matching my Firefox language. I have installed FF3b5 English(US), if I set GMail language to English(UK) or Norwegian the contacts and chat won't load.
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: