a iframe-window set as the focusedWindow still has focus after the iframe is set hidden

NEW
Unassigned

Status

()

defect
9 years ago
a year ago

People

(Reporter: mano, Unassigned)

Tracking

(Depends on 1 bug)

unspecified
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -)

Details

Attachments

(1 attachment)

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.
blocking2.0: ? → final+

Comment 1

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

Comment 3

9 years ago
The former.

Bugs 570835 and 561940 are also related.
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.
Neil continues to think this blocks. Throwing it his way.
Assignee: nobody → enndeakin

Comment 6

9 years ago
One of the ime tests fails with this patch I think, so I need to investigate it.
Attachment #498223 - Flags: feedback?(Olli.Pettay)
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.
Attachment #498223 - Flags: feedback?(Olli.Pettay) → feedback+

Comment 8

9 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?
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?

Comment 10

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

It probably doesn't.
blocking2.0: final+ → ---
I think the right thing to do here is to let the drivers retriage this...
blocking2.0: --- → ?
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.
blocking2.0: ? → -

Updated

7 years ago
Duplicate of this bug: 787842
Any updates?  We should fix this for whatever the latest release is..
No longer blocks: gecko-games

Updated

4 years ago
Assignee: enndeakin → nobody
Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336
Component: XP Toolkit/Widgets: XUL → XUL
You need to log in before you can comment on or make changes to this bug.