User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090802 Minefield/3.6a1pre (.NET CLR 4.0.20506) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090802 Minefield/3.6a1pre (.NET CLR 4.0.20506) When i go to http://www.getpersonas.com/ and hover the mouse pointer over a persona the content of the current tab is replaced with the content of the previous tab. Even though the tab with the persona is marked as active (see screenshot). The persona preview is loaded and visible until i move the mouse away from the area where the persona image preview is located on the getpersonas page. Reproducible: Always Steps to Reproduce: 1. Install Personas 1.3a1pre or latest stable (1.2.1) 2. go to http://www.getpersonas.com/ 3. Hover mouse over a persona Actual Results: Content of active tab get replaced with content of previous tab. Persona preview is working. Expected Results: Persona preview should load, tab content should be the same.
Only happens in current m-c, not in Shiretoko with the same profile.
Severity: normal → major
Summary: mouse over changes content of active tab to previous loaded tab → mouseover changes content of active tab to previous loaded tab
Version: unspecified → Trunk
Also, the first tab change after this bug isnt registred as long as it isnt the site where the persona preview was generated. For example if i have three tabs open, 1 2 3. the tab with persona preview is number 3, and number 2 was the last visited. when i hover over the persona i jump back to tab 2 as already described. Then, if i click tab 1, the content of tab2 is still being shows, even though tab 1 is the selected one.
I see this too on the latest 3.6a2pre nightly build for Linux (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a2pre) Gecko/20090810 Minefield/3.6a2pre) but with two variations: 1. the content of the gallery page gets replaced by the content of the tab to the *right* of the tab containing the gallery page; 2. Personas doesn't enter preview mode, it just flashes the moused-over persona briefly before returning to the currently selected persona. This may well be a Firefox/platform bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86 → All
I also get this bug when selecting (and previewing) a new persona from either the persona menu, or from a persona web site. After some reading and testing it seems like all calls to _applyPersona reproduces the bug. More specific, the call to this._header.style.backgroundImage = "url(" + this._escapeURLForCSS(headerURI.spec) + ")"; make the bug occur. Removing that line will fix the bug, but of course also not load the header image.
On IRC, Espen noted that Firefox builds from August 1 don't exhibit the problem, while builds from August 2 do exhibit it, and that it looks like http://hg.mozilla.org/mozilla-central/rev/0c0ad985df66 is the checkin that regressed this behavior. Thus I suspect that this is a Firefox bug caused by that checkin, so I'm moving this to the Firefox product and cc:ing its committer.
Assignee: cbeard → nobody
Component: Personas → General
Product: Mozilla Labs → Firefox
QA Contact: personas → general
Target Milestone: -- → ---
(In reply to comment #6) > On IRC, Espen noted that Firefox builds from August 1 don't exhibit the > problem, while builds from August 2 do exhibit it, and that it looks like It could still be a Personas bug or something that needs to be fixed in Personas code, though. > http://hg.mozilla.org/mozilla-central/rev/0c0ad985df66 is the checkin that > regressed this behavior. This isn't actually a check-in, but a merge from mozilla-central to tracemonkey.
(In reply to comment #7) > It could still be a Personas bug or something that needs to be fixed in > Personas code, though. Yes, of course. I don't know for a fact that this is a Firefox/Gecko bug, I just suspect that it is. > > http://hg.mozilla.org/mozilla-central/rev/0c0ad985df66 is the checkin that > > regressed this behavior. > > This isn't actually a check-in, but a merge from mozilla-central to > tracemonkey. Right!
Created attachment 393926 [details] reduced testcase Here's a reduced testcase that demonstrates the bug. Steps to reproduce: 1. set signed.applets.codebase_principal_support to true; 2. open two tabs; 3. load some web page in the second tab (the one on the right); 4. load the testcase in the first tab (the one on the left); 5. when prompted to allow the testcase to have "enhanced capabilities", press the Allow button. Expected results: nothing happens. Actual results: the content of the page in the second tab appears in place of the content in the first tab. Note that this only happens the first time you run the testcase, presumably because the testcase sets style.backgroundImage to the same value on subsequent runs, and setting that property to the same value doesn't trigger whatever rendering/repainting is responsible for the bug. Don't forget to set signed.applets.codebase_principal_support back to false after running the testcase if you are testing in a persistent profile and don't normally have that preference set to true.
Simplified STR: - open two tabs with different content - open the error console - execute top.opener.document.documentElement.style.backgroundImage = "url(http://www.getpersonas.com/static/1/6/16/tbox-firefox_b.jpg)"; Is this a regression? Does it happen with 3.5? 3.0?
Oh right, comment 6 says this is a regression. Still need a proper range.
(In reply to comment #10) > Is this a regression? Does it happen with 3.5? 3.0? As far as i have tested it only happens after the tracemonkey merge the 2nd of August, namely starting from this nightly: 2009-08-02-04-mozilla-central 2009-08-01-04-mozilla-central do not suffer from the regression. 3.5 is not affected, and based on that the Personas extension was around at 3.0 i guess it does not happen there either.
2009-08-01-04 is c99ec9f95c64, 2009-08-02-04 is 8366e5cc9f57. There's no tracemonkey merge involved, as far as I can see. http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c99ec9f95c64&tochange=8366e5cc9f57
Component: General → General
Product: Firefox → Core
QA Contact: general → general
Version: Trunk → 1.9.2 Branch
As Olli Pettay [:smaug] pointed out on IRC he suspected that http://hg.mozilla.org/mozilla-central/rev/79db77b024f7 was the cause of the regression. I backed out that patch and rebuilt a fresh copy, and can confirm that the regression is now gone.
(In reply to comment #14) > I backed out that patch and rebuilt a fresh copy, and can confirm that the > regression is now gone. Very helpful, thanks.
Component: General → XUL
QA Contact: general → xptoolkit.widgets
Assignee: nobody → roc
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
Created attachment 396398 [details] [diff] [review] fix What's happens here is that nsDeckFrame calls viewManager->SetViewVisibility to hide the view of the tab child(ren) that should be hidden. But if anything causes the hidden tab content to be reflowed or otherwise have its view synced with the frame --- as Personas does here --- nsContainerFrame::SyncFrameViewProperties will call SetViewVisibility to show the view, and the tab appears and this bug occurs. Basically we have a conflict between nsDeckFrame's explicit management of the view and SyncFrameViewProperties implicitly managing the view. This patch fixes the conflict by making SyncFrameViewProperties only manage the views for frames which report !SupportsVisibilityHidden, and removing that flag from nsObjectFrame, so only nsSubdocumentFrames are managed this way. So after this patch: * nsSubdocumentFrames have their view visibility managed by SyncFrameViewProperties as before. * nsObjectFrames are changed to manage their own view visibility exclusively. It's pretty clear from nsObjectFrame::DidSetStyleContext etc that that's what it needs. * nsMenuPopupFrames are changed to manage their own view visibility exclusively as well. Again, it's clear from inspecting nsMenuPopupFrame that that's what it expects. * The views for all other frame types are created visible, so not setting their visibility in SyncFrameViewProperties is unchanged behaviour from setting them to visible. This patch also fixes bug 508174.
Attachment #396398 - Flags: review?(dbaron)
Whiteboard: STR: comment 10 → STR: comment 10 [needs review]
Comment on attachment 396398 [details] [diff] [review] fix As far as I can tell, no callers pass nonzero aFlags to SyncFrameViewProperties, which means that both the aFlags argument and NS_FRAME_NO_VISIBILITY can be removed. That could be a separate patch, though. Or should something in reflow code be passing it through to SyncFrameViewProperties? (Looking through the callers that set NS_FRAME_NO_VISIBILITY, though, I also find a site in nsComboboxControlFrame.) > // Make sure visibility is correct Please expand this comment to say that you're only doing anything for SubDocumentFrames? r=dbaron
Attachment #396398 - Flags: review?(dbaron) → review+
Yes, I should do another cleanup patch after this.
Whiteboard: STR: comment 10 [needs review] → STR: comment 10 [needs landing]
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: STR: comment 10 [needs landing] → STR: comment 10 [needs 1.9.2 landing]
Could this have broken All-in-One Gestures?
I think this broke personas completely, also. It might have fixed the tab content / focus problem (testcase in #9 no longer seem to trigger the regression), but the skinning function of personas seems broken.
Sorry. File new bug(s) with steps to reproduce, please.
comment 19 says its landed two weeks ago, but i still see this happening on trunk. shall i reopen? Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a2pre) Gecko/20090915 Namoroka/3.6a2pre
You're on 1.9.2. This still needs to land there.
oops, indeed i was. Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20090915 Minefield/3.7a1pre
Status: RESOLVED → VERIFIED
Whiteboard: STR: comment 10 [needs 1.9.2 landing] → STR: comment 10 [needs 192 landing]
Tue Aug 25 00:44:42 2009 -0700 (at Tue Aug 25 00:44:42 2009 -0700): http://hg.mozilla.org/releases/mozilla-1.9.2/rev/5be4fba1bc35
status1.9.2: --- → beta1-fixed
Whiteboard: STR: comment 10 [needs 192 landing] → STR: comment 10
You need to log in before you can comment on or make changes to this bug.