Google reader "list view" and "expanded view" render incorrectly




11 years ago
11 years ago


(Reporter: Gabriel Chadwick, Assigned: roc)


({regression, testcase})

regression, testcase
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)




(4 attachments, 1 obsolete attachment)



11 years ago
Google reader list view and expanded view do not render correctly with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070212 Minefield/3.0a3pre . They are not at the correct emplacement. See image in attachement.

Comment 1

11 years ago
Created attachment 254912 [details]
Example of the bug


11 years ago
Keywords: qawanted


11 years ago
Ever confirmed: true
The trouble is that the bug that caused this is already checked in on branch. 
(In reply to comment #2)
> The trouble is that the bug that caused this is already checked in on branch.

Wrong info. Only trunk regression. There was a trunk build in the wrong folder. Sorry for the false alarm.
I see a regression between 2005-08-24:09 and 2005-08-24:12. I didn't test all builds since then, but only a few random and it still looks the same.

Comment 4

11 years ago
It would be great if we could get a minimized testcase (or even a static version of the page) so that we don't lose track of this when Google changes things.
Keywords: qawanted
Created attachment 255626 [details]

This is the minimised testcase that I came up with.
This looks similar to the one in bug 349255.
I get a regression range between 2006-12-07 and 2006-12-08, which is totally different from the one in comment 3.
I'll also a (much) less minimised testcase (in case I minimised in the wrong way).
Created attachment 255627 [details]
unminimised testcase


11 years ago
Blocks: 300030
Keywords: testcase
Created attachment 260508 [details]
another minimized testcase

Martijn's (first) minimized testcase actually WFM.
This is a minimized testcase I created independently (before realizing the bug was already reported). Note the "overflow-y:hidden" on the outer div, which is necessary to produce the bug.
Well, that's odd, because your testcase is WFM, and my (first) minimized testcase still shows the bug for me, using the latest trunk build.
Maybe this is resolution dependant? I'm using 1440*900px, and I have 26px wide scrollbars.
Oops - I do see a scrollbar on your testcase - so it doesn't really qualify as WFM. Nevertheless, I don't think it captures the original issue, which is the "expanded view" and "list view" texts appearing on top of each other, rather than side by side. That's what I'm seeing with my testcase on trunk. 
Strange, the "expanded view" and "list view" are appearing side by side on my computer, using the latest trunk build.
For the record, I'm seeing them on top of each other (in my testcase) with:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a4pre) Gecko/20070403 Minefield/3.0a4pre

On the "unminimized testcase", I see "Feed settings..." and "List view" on the top row, and "Expanded view" on a second row, below "Feed settings...".


Comment 12

11 years ago
I still get the bug with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070403 Minefield/3.0a4pre ID:2007040304 [cairo] on The first testcase show's a scroll bar for me. The other ones I don't really understand the behavior i am supposed to get... Sorry.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070404 Minefield/3.0a4pre
I see no difference in the position of the buttons of the builds 2006-12-07 and 2006-12-08. But I do see difference between the builds I mentioned in comment 3. So I think it is indeed influenced by the screen resolution.
Duplicate of this bug: 376474

Comment 15

11 years ago
Still being seen with Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9a7pre) Gecko/2007070604 Minefield/3.0a7pre. Is there somebody working on this (I assume no since there is assignee). Hope it will get solved.


11 years ago
Flags: blocking1.9?
Created attachment 271715 [details]
another testcase

This testcase (unlike the previous one) has the same regression range as the original page (the range given at comment #3).
It also shows clearly that this is a pixel-rounding issue, which points to bug 139843 (fixed within this range).
Attachment #260508 - Attachment is obsolete: true


11 years ago
Blocks: 139843
No longer blocks: 300030
Bernd, do you want this?

Comment 18

11 years ago
No, due to time constraints the only thing that I will touch are table crash bugs
Assignee: nobody → roc
Flags: blocking1.9? → blocking1.9+

Comment 20

11 years ago
Sill not viewing correctly with Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9a8pre) Gecko/2007090504 Minefield/3.0a8pre and accounting the major update the google reader team put in inclunding the search function. So this looks like there will be no change from google for now anyway. Any action ?
This might be grist for Eli's mill

Comment 22

11 years ago
I think bug 139843 should be backed out; I don't think the fix makes sense, and the testcase from that bug works fine on trunk anyway.

(Attachment 255626 [details] is a completely different issue.)

Comment 23

11 years ago
Is this going to be fixed before M8? which is due in about a week. Google Reader is one of the most visited sites, so I believe this should be a priority.
Fixed by backing out fix for bug 139843.
Last Resolved: 11 years ago
Resolution: --- → FIXED

Comment 25

11 years ago
Confirmed with Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9a8pre) Gecko/2007091804 Minefield/3.0a8pre
You need to log in before you can comment on or make changes to this bug.