This is something of a spin-off from Bug 622985 -- "My T-Mobile" login page no longer has a plugin crash, but it shows this visual glitch instead. STEPS TO REPRODUCE: 1. Open two tabs 2. In one tab, enter the URL https://my.t-mobile.com/Login/MyTMobileLogin.aspx 3. Press 'enter' to start loading the URL, and *immediately* switch to the other tab. 4. Once the T-Mobile page has loaded (throbber circle stops spinning), switch back to its tab. ACTUAL RESULTS: "Log In To My T-Mobile" text is mispositioned on the first paint. Anything that triggers a repaint will make it snap to its correct position, though. (e.g. clicking the desktop, clicking the title bar, scrolling.) This is a regression w.r.t. Firefox 3.6 -- adding 'regression' keyword.

(You can reproduce this just by reloading* "My T-Mobile" and immediately switching tabs, too.) *BTW, Ctrl-R doesn't seem to work for reloading, since by default, focus goes to a "phone number" text field with an onkeypress handler that rejects anything but number keys. So you have to manually click the "reload" button (or focus the password field and then do Ctrl-R)

This actually regressed a few weeks back, in late December. Regression range: 20101227030354 24b63f638579 20101228030339 e928817fb4e9 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=24b63f638579&tochange=e928817fb4e9

Nothing in that range jumps out, except perhaps http://hg.mozilla.org/mozilla-central/rev/a07894326d5d : Robert O'Callahan — Bug 615870. Part 2: Track per-display-root-frame 'update layer tree' state bit. r=tnikkel a=b-f

Confirmed with targeted builds that that's the changeset that did it. A build from a07894326d5d exhibits the bug; a build from its parent (0a7d57ee6a0a) does not.

I'm guessing that the following chunk of the regressing cset is what caused the problem, in nsIFrame::InvalidateLayer -- this is the only chunk of that patch to mention plugins: > - InvalidateWithFlags(aDamageRect, INVALIDATE_NO_THEBES_LAYERS); > + PRUint32 flags = INVALIDATE_NO_THEBES_LAYERS; > + if (aDisplayItemKey == nsDisplayItem::TYPE_VIDEO || > + aDisplayItemKey == nsDisplayItem::TYPE_PLUGIN) { > + flags = INVALIDATE_NO_UPDATE_LAYER_TREE; > + } > + > + InvalidateWithFlags(aDamageRect, flags); Testing that theory...

yup -- if I comment out the |flags| tweak in comment 5, the bug goes away. I'm assuming that that's not the fix we want here, though...

(In reply to comment #6) > I'm assuming that that's not the fix we want here, though... Correct.

Strange, switching tabs should cause a layer tree update.

Daniel, can you still reproduce this on the latest trunk? I could repro on mac trunk...

"could" or "couldn't"? :-)

(In reply to comment #9) > Daniel, can you still reproduce this on the latest trunk? Yes, I can still reproduce, using yesterday's nightly (latest trunk as of when ehsan posted) Fresh profile, Ubuntu 10.10 x86, flash version "Shockwave Flash 10.1 r102" Mozilla/5.0 (X11; Linux i686; rv:2.0b11pre) Gecko/20110128 Firefox/4.0b11pre

One interesting data point: if I force-enable layers acceleration, the bug goes away. That might be why ehsan couldn't (I'm assuming he meant :)) reproduce this on mac -- since layers is default-enabled for recent OS X versions now. (Or it might also depend on a quirk in flash-on-linux or something.)

(In reply to comment #10) > "could" or "couldn't"? :-) "couldn't", of course! :-)

OK, I could reproduce it on Linux/Windows with acceleration turned off. It didn't happen for me on Mac with/without acceleration, and on Linux/Windows with acceleration turned on.

So, roc, let's say that I wanted to look into this. Where would I start? :-)

The problem is probably that nsRootPresContext::UpdatePluginGeometry isn't being called at the right time (just before/just after the tab switch). So check that. If it's not being called, figure out why :-). If it is being called, figure out why the plugin widget didn't end up in the right place.

I'm not sure that the widget is in the wrong place: I think it's reasonably likely that the script code sIFR (the Flash widget) is using to calculate the position for its text is somehow getting coordinates which are not correct. But that's just speculation, you'd have to log the NPRuntime stuff in order to find out.

(In reply to comment #17) > I'm not sure that the widget is in the wrong place: I think it's reasonably > likely that the script code sIFR (the Flash widget) is using to calculate the > position for its text is somehow getting coordinates which are not correct. But > that's just speculation, you'd have to log the NPRuntime stuff in order to find > out. Can you please provide a pointer on what I need to log, exactly? This is kind of new stuff for me, so I'm just trying to get a good feeling on where to start.

If you're on Windows, Spy++ will show you where the widget has been positioned. Setting gDumpPluginList=1 will log some good stuff.

I was able to reproduce this on Windows with hardware acceleration enabled in FF4b10, but the time window for the glitch was *extremely* small, perhaps because hwaccel makes rendering so much faster. I haven't been able to reproduce it since then, regardless of whether hwaccel is on. The widget has no position on Windows under Spy++ (I checked both the firefox process and plugin-container). This is probably because the sIFR embed/object are wmode=transparent. I built with gDumpPluginList=1 and loaded the page and didn't see anything interesting in the layer tree: the plugin bounds were always (9180,14100,56460,2220) - (153, 235, 941, 37) in pixels - which looks correct to me. I did find a roundabout way to verify that the strange behavior is occuring on Win7, though: If you have taskbar thumbnails enabled, and open the page in a background tab, the thumbnail for the page will show the incorrect rendering until you activate the tab (at which point it will render correctly).

Turning off OOPP fixes the problem for me.

Kevin, did you also try comment 16?

It is a windowless plugin, so it doesn't have a widget.

If I apply the patch from 631388 to disable centering, this bug goes away for me on Linux.

Fixed by 631388.

631388 got reopened.

Bookkeeping changes as per comments in this bug.

Something still isn't right on that T-Mobile page in Beta 12. The "Log In to My T-Mobile" text starts on the left, changes to a different font, moves to the center, and then moves back to the left in the original font. It happens on a clean install in Windows 7 x64.

Did it do that before?

Bug 636244?

The font face also changes on 3.6 on another PC, but it doesn't go from left to center to left like it does in Beta 11 and Beta 12. I've seen a Mozilla page that quickly refreshed itself with a different font too, but I can't find it now. I guess it's unrelated to this. I'll keep looking for an existing Bug. Thanks.

You can just go ahead and file a new bug.