STEPS TO REPRODUCE: 1. Load URL ( http://opentable.com/start.aspx?m=4 ) 2. Click in the "Enter Restaurant Name" field, and type 'a' --> JS autocomplete dropdown appears 3. Hover mouse over autocomplete dropdown OBSERVED RESULTS: autocomplete dropdown starts flickering like mad Tested using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3) Gecko/2008020513 Firefox/3.0b3 The site works in FF2. (no flickering)
Created attachment 304834 [details] mostly-minimized testcase (zipped) Here's a mostly-minimized testcase. You can also try out the testcase at: http://people.mozilla.com/~dholbert/tests/418906/opentable/opentable.html
Note: It looks like OpenTable uses the "Wick" JS autocomplete library. ( http://wick.sourceforge.net ) But this bug does NOT reproduce on the Wick sample page, available at: http://wick.sourceforge.net/wick_sample/ So, this could mean that OpenTable is using an old (non-FF3-compatible) version of Wick, and/or maybe they're just using different features of Wick than those used on Wick's sample page.
This regressed in two steps, first regression was that the menu only shivers as long as you move your mouse, that is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-05-10+09%3A00&maxdate=2006-05-10+23%3A00 Second regression is that the menu also shivers when your mouse stands still, that was in Oct or Nov 2006.
In November, between the IDs 2006111607 and 2006111610. http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-11-16+06%3A00&maxdate=2006-11-16+11%3A00
(In reply to comment #4) > In November, between the IDs 2006111607 and 2006111610. Maybe due to bug 306149? The checkin message mentions "mouse event synthesis", and maybe that's why we switched from shivering only when mouse moves to shivering even when mouse stands still.
(In reply to comment #3) > This regressed in two steps, first regression was that the menu only shivers as > long as you move your mouse And that first one is probably a regression from bug 326273 "Implement nsIThreadManager", which seems to be the dominant checkin in that range. Thanks for tracking down thosese ranges!
(In reply to comment #6) > Thanks for tracking down thosese ranges! er... 'those ranges' :)
This should at least be investigated.
Created attachment 305106 [details] testcase This isn't completely directly deduced from the site, but I think it's basically this issue. When hovering over the first yellow box, it can disappear or give a red flicker, while this doesn't happen with the second yellow box at all.
-->layout->View Rendering == roc
Component: Event Handling → Layout: View Rendering
QA Contact: events → layout.view-rendering
(In reply to comment #9). > When hovering over the first yellow box, it can disappear or give a red > flicker, while this doesn't happen with the second yellow box at all. > FWIW, I do get some minor flickering on the second yellow box when I move my mouse back and forth across it. (But, like Martijn, I see no flickering when I simply hover over that second box.)
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Assignee: nobody → roc
Here we have a cycle of the following 1. synthesized mouse-move 2. fires onmouseover 3. sets innerHTML 4. tears down frame subtree for the DIV and constructs new, not-reflowed frames 5. asynchronously reflow the frames 6. Synthetic mouse-move event posted, go to step 1 That will consume CPU, probably did in Firefox 2, but it shouldn't flicker because whenever we paint, we flush reflows first, so even if we paint after step 4 we should reflow early and paint the correct layout. But it turns out that we actually are painting without reflowing, hence the flicker. The reason: the paint event comes in on the IFRAME's widget, so we call WillPaint() on the IFRAME's presshell, which is not where the reflow needs to happen. Boris has a comment in nsViewManager:: // XXXbz do we need to notify other view observers for viewmanagers // in our tree? Yes! More fodder for compositor, but what, if anything, should we do for Gecko 1.9? I'm leaning towards "nothing", because the obvious fix would be to try to flush all presshells in the view manager tree, which would be fragile and carry major performance risk. Or would it?
Whiteboard: [needs feedback]
I think reflowing up the parent document chain, at least, shouldn't be too fragile and shouldn't hurt performance too much...
That would fix this bug, but it wouldn't fix the simple variant where the DIV is placed in a sibling IFRAME. So is it worth doing at all?
I suppose we could also just flush all the observers for viewmanagers that have the same root as us...
But yeah, I wouldn't worry about this too much, honestly. Let's get compositor working instead. ;)
Assignee: roc → nobody
You need to log in before you can comment on or make changes to this bug.