Asaf Romano (gone) Reporter
	Description • 14 years ago

Found this while investigating bug 574353.

If a the window of a xul iframe is set as the focused window, and no element within it actually received focus, the iframe-window would still be marked as the focused window if the iframe is set hidden.

I cannot tell if this is a regression.

	Neil Deakin
	Comment 1 • 14 years ago

A simple test shows that no 'pagehide'/'unload' event fires at the frame's document when it is hidden in this way, so the focus manager isn't getting notified.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 2 • 14 years ago

What does "iframe is set hidden" mean? display: none? visibility: hidden?

In the first case we could detect that the iframe's rendering object is deleted,
but not sure what to with the latter case.

	Neil Deakin
	Comment 3 • 14 years ago

The former.

Bugs 570835 and 561940 are also related.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 4 • 14 years ago

Would be great to have a testcase here.

So, if the case is display: none, nsSubDocumentFrame::DestroyFrom could
probably unfocus the window/element in the iframe.

	Johnathan Nightingale [:johnath]
	Comment 5 • 14 years ago

Neil continues to think this blocks. Throwing it his way.

	Neil Deakin
	Comment 6 • 14 years ago

One of the ime tests fails with this patch I think, so I need to investigate it.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 7 • 14 years ago

Comment on attachment 498223 [details] [diff] [review]
work in progress

>-[scriptable, uuid(5cb91200-53f6-4d35-989d-1d28ad80a0d4)]
>+[scriptable, uuid(F91024AD-F5A8-42CB-851E-57033458F69C)]
Can't take interfaces changes to trunk atm.

There is nsIFocusManager_MOZILLA_2_0_BRANCH , which could be perhaps used,
or do we need nsIFocusManager_MOZILLA_2_0_BRANCH_2 for this?
Perhaps bsmedberg could know that.



>@@ -248,19 +248,20 @@ interface nsIFocusManager : nsISupports
>    *
>    * If aNeedsFocus is true, then focus events are expected to be fired on the
>    * window if this window is in the focused window chain.
>    */
>   [noscript] void windowShown(in nsIDOMWindow aWindow, in PRBool aNeedsFocus);
> 
>   /**
>    * Called when a document in a window has been hidden or otherwise can no
>-   * longer accept focus.
>+   * longer accept focus. If aDestroyed is true, then the window is being
>+   * destroyed and focus should move elsewhere.
>    */
>-  [noscript] void windowHidden(in nsIDOMWindow aWindow);
>+  [noscript] void windowHidden(in nsIDOMWindow aWindow, in PRBool aDestroyed);
aDestroyed is strange name for the parameter. The window isn't being destroyed, only its
presentation.

	Neil Deakin
	Comment 8 • 14 years ago

It seems that the test_imestate.html fails with this patch because setting designMode="on" causes the document frame to be destroyed (and recreated perhaps?)

Any thoughts here as to why or how to work around this?

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 9 • 14 years ago

Ah, interesting problem. And hard to resolve.
What does 3.6 do? Or 3.5 which doesn't have focusmanager, IIRC.


Btw, why is this a blocker?

	Neil Deakin
	Comment 10 • 14 years ago

(In reply to comment #9)
> Btw, why is this a blocker?

It probably doesn't.

	(no longer active)
	Comment 11 • 14 years ago

I think the right thing to do here is to let the drivers retriage this...

	Dietrich Ayala (:dietrich)
	Comment 12 • 14 years ago

Forecast is mildly annoying with easy workaround (focus something). Blocking-.

Please re-request blocking if you have a scenario which is bad enough that we should hold the release for a fix.

	Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)
	Comment 14 • 11 years ago

Any updates?  We should fix this for whatever the latest release is..

	Firefox Bug Husbandry Bot
	Comment 15 • 6 years ago

Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336