Invalidation bug in slashdot.org headings

RESOLVED WORKSFORME

Status

()

Core
Layout
RESOLVED WORKSFORME
6 years ago
6 years ago

People

(Reporter: mats, Assigned: mattwoodrow)

Tracking

({dogfood, regression, top100})

unspecified
x86_64
Linux
dogfood, regression, top100
Points:
---

Firefox Tracking Flags

(firefox18-)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
Created attachment 668873 [details]
screenshot

STEPS TO REPRODUCE
1. load http://slashdot.org/
2. grab the scrollbar thumb, drag it up and down for a while

ACTUAL RESULT
The white text in a heading is missing, see screenshot.
Hovering the heading makes the text render correctly.

PLATFORMS AND BUILDS TESTED
Bug occurs in Nightly 18.0a1 (2012-10-06) on Linux64.

I think it's a regression in the last week or so.

Updated

6 years ago
Assignee: nobody → matt.woodrow
tracking-firefox18: ? → +
(Assignee)

Comment 1

6 years ago
I can't reproduce this on mac (both with and without accelerated layers). It's also not obviously related to my changed (though it very well could be).

Need the regression range here I think.
(Reporter)

Comment 2

6 years ago
Hmm, I can't reproduce this on slashdot.org today.  I'll try to find a regression-
range when I can reproduce it reliably again.

Today I saw two other invalidation bugs:  when switching tab one of the tab
heads (not the current) went blank.  In bugzilla, clicking the date of a patch
attachment (to scroll to the corresponding comment) made the entire URL bar
blank.  Neither was reproducible and just hovering the blank area restored it.
(In reply to Mats Palmgren [:mats] from comment #2)
> Hmm, I can't reproduce this on slashdot.org today.  I'll try to find a
> regression-
> range when I can reproduce it reliably again.

Hey Mats, was this reproducible agn or some how fixed now ? We need the regression range to proceed if this still happens .Will be very helpful if you can pass that on in case you see this again.
> 
> Today I saw two other invalidation bugs:  when switching tab one of the tab
> heads (not the current) went blank.  In bugzilla, clicking the date of a
> patch
> attachment (to scroll to the corresponding comment) made the entire URL bar
> blank.  Neither was reproducible and just hovering the blank area restored
> it.

I understand these are not easily reproducible but any chance you ran into them again in these 2 weeks ?
(Reporter)

Comment 4

6 years ago
I saw the tab painting bug again just now, in 19.0a1 (2012-10-26) Linux64.
This time it wasn't just blank.  I had 8 tabs open in this window, tab 5
open, when moving the mouse in/out of the tab bar (over tab 4), then tab 3
shifted shade of grey about 10% each time until it was nearly black, then it
turned blank briefly, and then restored when I hovered it (tab 3).
(the tabs was opened from a bookmark menu with "open all in tabs")

Like the slashdot.org scroll bug, it's 100% reproducible in that window
when it occurs.

I tried to reproduce the above with a fresh profile but did not succeed.
(I use AdblockPlus in my default profile, and flash disabled, fwiw)

Perhaps it's the same underlying issue as bug 805696? (which has STR)
(Reporter)

Comment 5

6 years ago
Created attachment 675760 [details]
video of tab painting error
(Reporter)

Comment 6

6 years ago
Created attachment 675967 [details]
screenshot #2

The slashdot.org scroll problem occurred again just now, Nightly 19.0a1
(2012-10-26) Linux64.
This time I saved a "web page complete" copy of it; loading that copy
reproduced the problem.  I've seen this problem 8-10 times now and every
time it's the heading below the grey "Today/Yesterday" speech bubbles
that's missing the text (see screenshot #2).  Notice also how the image
to the right (the globe) appears to be *under* the green bar.  Are the
display items added/sorted in the wrong order somehow?

(I'll try to reproduce the problem with the saved copy after I restart
later.  Let me know if you want me to test something in this session
while the problem is reproducible.)
(In reply to Mats Palmgren [:mats] from comment #6)
> Created attachment 675967 [details]
> screenshot #2
> 
> The slashdot.org scroll problem occurred again just now, Nightly 19.0a1
> (2012-10-26) Linux64.
> This time I saved a "web page complete" copy of it; loading that copy
> reproduced the problem.  I've seen this problem 8-10 times now and every
> time it's the heading below the grey "Today/Yesterday" speech bubbles
> that's missing the text (see screenshot #2).  Notice also how the image
> to the right (the globe) appears to be *under* the green bar.  Are the
> display items added/sorted in the wrong order somehow?
> 
> (I'll try to reproduce the problem with the saved copy after I restart
> later.  Let me know if you want me to test something in this session
> while the problem is reproducible.)

:Mats, is this still reproducible at this time ? I reached out to :mattwoodrow who is assignee of this bug and he is having a hard time reproducing it. Any help with STR you may have can make this actionable at this time. Thanks !
(Reporter)

Comment 8

6 years ago
Yes, I still see the problem on slashdot.org and the repaint error in the tab bar
recorded in the attached video in my current Nightly which is dated 2012-11-05.
I can reproduce the tab bar problem pretty easily:
1. open a new window
2. in a sub-menu in the bookmark menu, click "open all in tabs", do this a few
   times to make sure the tab bar is "filled out" also after you close a few
   tabs
3. click on tab somewhere in the middle, close it
4. move the mouse away from the tab bar so that the tab resize animation
   starts
5. move the mouse back over the tab to the left of the one that is now
   the current one
=> the tab to left of the one you're now hovering gets darker -
   moving the mouse out below it and back makes the tab to the left
   darker each time (as the video shows)

(not sure if the bookmark menu step is needed, I think you just need to
open enough tabs to fill out the tab bar, even after closing a few)

The slashdot.org problem is more intermittent, it occurs every other day or so,
but when it occurs it's reproducible by dragging the scrollbar thumb up and down
for while.
(Assignee)

Comment 9

6 years ago
Mats: The tab bar problem sounds like bug 795648.
(Assignee)

Comment 10

6 years ago
I can't reproduce anything with the above STR either.

I don't need to move the mouse after closing the tab though, the tab moving animation starts immediately.
(Reporter)

Comment 11

6 years ago
(In reply to Matt Woodrow (:mattwoodrow) from comment #9)
> Mats: The tab bar problem sounds like bug 795648.

Maybe.  The screenshots in that bug looks like random pixels, and also outside
the tab head.  I've never seen random pixels for the tab head bug here, just an
accumulative greying inside it.  (It may be the same underlying bug though,
with different results on OSX with HWA / Linux64 without HWA.)
(Reporter)

Comment 12

6 years ago
I've found a STR that I can reliably reproduce, filed as bug 810302 in case
it turns out to be a different bug.
(Assignee)

Comment 13

6 years ago
Do you still see this now that bug 810302 has been fixed?
(Reporter)

Comment 14

6 years ago
I still see the tab painting error described in comment 8 in Nightly (2012-12-06)
on Linux64.  I haven't seen the slashdot error (yet) but ping me again in a week.
(Assignee)

Comment 15

6 years ago
Ok, thanks Mats.

I still can't reproduce the tab painting issue. Do you have any custom theming applied? And which distro/version is that? It looks very different to my nightlies on Ubuntu 12.04.

Maybe we should split the tab issue into a separate bug and try get QA help on it.
(In reply to Matt Woodrow (:mattwoodrow) from comment #15)
> Ok, thanks Mats.
> 
> I still can't reproduce the tab painting issue. Do you have any custom
> theming applied? And which distro/version is that? It looks very different
> to my nightlies on Ubuntu 12.04.
> 
> Maybe we should split the tab issue into a separate bug and try get QA help
> on it.

Sounds like the right thing to do, but please be clear with QA what we'd like them to do - find another reproducing case to better understand the affected config?

As we come closer to FF18's release, it's doubtful that we'd block ship on either the slashdot/tab issues. There haven't been other instances of these bugs reported in the wild.
(Reporter)

Comment 17

6 years ago
I haven't seen the original problem at slashdot.org for a while, so wfm.
I filed bug 821533 for the tab repainting problem.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Keywords: regressionwindow-wanted

Updated

6 years ago
tracking-firefox18: + → -
You need to log in before you can comment on or make changes to this bug.