Espen Fjellvær Olsen Reporter
	Description • 15 years ago

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.

	Espen Fjellvær Olsen Reporter
	Comment 1 • 15 years ago

Screenshot of the actual result

	Espen Fjellvær Olsen Reporter
	Comment 2 • 15 years ago

Only happens in current m-c, not in Shiretoko with the same profile.

	Espen Fjellvær Olsen Reporter
	Comment 3 • 15 years ago

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.

	Myk Melez [:myk] [@mykmelez]
	Comment 4 • 15 years ago

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.

	Espen Fjellvær Olsen Reporter
	Comment 5 • 15 years ago

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.

	Myk Melez [:myk] [@mykmelez]
	Comment 6 • 15 years ago

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.

	Dão Gottwald [:dao]
	Comment 7 • 15 years ago

(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.

	Myk Melez [:myk] [@mykmelez]
	Comment 8 • 15 years ago

(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!

	Myk Melez [:myk] [@mykmelez]
	Comment 9 • 15 years ago

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.

	Dão Gottwald [:dao]
	Comment 10 • 15 years ago

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?

	Dão Gottwald [:dao]
	Comment 11 • 15 years ago

Oh right, comment 6 says this is a regression. Still need a proper range.

	Espen Fjellvær Olsen Reporter
	Comment 12 • 15 years ago

(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.

	Dão Gottwald [:dao]
	Comment 13 • 15 years ago

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

	Espen Fjellvær Olsen Reporter
	Comment 14 • 15 years ago

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.

	Dão Gottwald [:dao]
	Comment 15 • 15 years ago

(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.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 16 • 15 years ago

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.

	David Baron :dbaron:
	Comment 17 • 15 years ago

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

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 18 • 15 years ago

Yes, I should do another cleanup patch after this.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 19 • 15 years ago

http://hg.mozilla.org/mozilla-central/rev/d483401d922f

	Dão Gottwald [:dao]
	Comment 20 • 15 years ago

Could this have broken All-in-One Gestures?

	Espen Fjellvær Olsen Reporter
	Comment 21 • 15 years ago

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.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 22 • 15 years ago

Sorry. File new bug(s) with steps to reproduce, please.

	Tony Chung [:tchung]
	Comment 24 • 15 years ago

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

	Dão Gottwald [:dao]
	Comment 25 • 15 years ago

You're on 1.9.2. This still needs to land there.

	Tony Chung [:tchung]
	Comment 26 • 15 years ago

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

	Chris Pearce [:cpearce (Not reading bugmail)]
	Comment 28 • 15 years ago

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