385609 - Cannot type into an editor in a xul panel

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Asaf Romano (gone)]

An editor element inside a xul panel seems to be nonfunctional (at least on mac trunk+popup-rewrtie). This is the opposite of bug 385269 - the caret does appear when the editor is focused, but you cannot type.

See also bug 385536.

Comment 1

[Asaf Romano (gone)]

This is even worse on windows, just focusing the editor closes the panel.

Comment 2

[Neil Deakin]

I get the missing keybindings assertion.

###!!! ASSERTION: No binding found for the XBL window key handler.: 'binding', file /builds/trunk-menu/mozilla/content/xbl/src/nsXBLWindowKeyHandler.cpp, line 152

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

roc and I aren't the right people to triage the blocking1.9? flag here.  Not sure how to fix that...

Comment 4

[Neil Deakin]

I think there's a number of related or unrelated bugs with subframes in popups, different on each platform.

On Mac, the issue is that the key events are targeted at the widget for the main window, yet no element in the main window has the focus. Instead an element within the editor subshell has the focus. The effect is that the key events are being targeted at the <window> rather than the document in the editor.

On Windows, the popup disappears once the editor has loaded the page. Opening the popup again works though, but no mouse events get targeted at the editor. I haven't yet got far enough to see whether the Mac issue described above occurs on other platforms also.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Neil, what's your opnion on whether this should be a blocker?

Comment 6

[Neil Deakin]

There are three distinct bugs with using <editor>, <browser> or <iframe> in a
popup.

1. The key event issue described above. I have a mostly done fix here which is
to do a popups fixup in nsPresShell::HandleEvent much like is currently done
for mouse events.

2. The closing popups on page load bug is due to Windows adjusting the focus
between the popup and the main window several times. I filed bug 390197 on
this.

3. Mouse events don't get sent to child frames in popups. This can be fixed by
the views not connected in chrome hierarchy bug 130078. 

I don't think 1 or 2 are too hard to fix, so I think this more dependant on 3.

Comment 7

[Neil Deakin]

Attachment: redirect key event if the focus is in a subshell

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

A testcase here would be great.
Is the keyevent retargeted in this case (see ~line 5391 in nsPresShell)?
Are keyevents always handled using rootview?
Could you handle all this in the code which checks whether event is meant
for popups?

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #8)
> Could you handle all this in the code which checks whether event is meant
> for popups?

ah, no, that part is not for keyevents

Comment 10

[Neil Deakin]

Attachment: testcase

Olli, this is a testcase for this bug. The patch in bug 130078 is also needed to get mouse events to work.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

+          // When a popup is open, key events are always fired at the main
+          // window rather than the presshell containing the focus.

Why? Shouldn't we fix that?

Comment 12

[Neil Deakin]

(In reply to comment #11)
> +          // When a popup is open, key events are always fired at the main
> +          // window rather than the presshell containing the focus.
> 
> Why? Shouldn't we fix that?
> 

I had assumed that was by design, as mouse events are like that. Fixing it would require changing all the native widget implementations.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

popups capture mouse events, but IMHO key events should still go wherever the focus is.

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 274673 [details] [diff] [review]
redirect key event if the focus is in a subshell

Still trying to figure out if this is really what we want.

>+                      PresShell* shell = static_cast<PresShell*>(realShell);

Keep the shell alive while handling an event: nsRefPtr<nsPresShell> shell = ...

Is the rootview always the correct view to dispatch key events? What if the 
focused element is in scrolled content?

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 274673 [details] [diff] [review]
redirect key event if the focus is in a subshell


>+                      CallQueryInterface(domDoc, &document);

This AddRefs, so you leak documents.


I'll do still some tests, then r-/+

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #13)
> popups capture mouse events, but IMHO key events should still go wherever the
> focus is.
> 

I agree with this.

Comment 17

[Neil Deakin]

(In reply to comment #13)
> popups capture mouse events, but IMHO key events should still go wherever the
> focus is.
> 

How would the widget code know where the focus was?

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The widget code knows which widget has/had focus, right?

Comment 19

[Neil Deakin]

The thing here is that popups don't get activated, so the OS still fires keyboard events at the main window. At least that's whats happening on Windows.

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm confused.

If we want key events to go to popups, we should focus them. If we want key events to not go to popups, we should not focus them. What's the problem with that?

Comment 21

[Neil Deakin]

(In reply to comment #20)
> I'm confused.
> 
> If we want key events to go to popups, we should focus them. If we want key
> events to not go to popups, we should not focus them. What's the problem with
> that?
> 

I've tried to focus popups, but it doesn't work, possibly because only nsIDOMWindows can be focused. Do you have some insight that I don't?

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

if you put a focusable element like a textbox into the popup, it can receive focus, right? I assume we pass focus to the nearest native widget for the focused element. So I'm not sure what's going on but it should be fixable.

Comment 23

[Neil Deakin]

(In reply to comment #22)
> if you put a focusable element like a textbox into the popup, it can receive
focus, right?

The textbox can receive focus because its in the same document as the activated parent window.
 
I assume we pass focus to the nearest native widget for the
> focused element. 

When a popup is open, the events get targeted at the parent window (the nsIDOMWindow). But the content within the xul popup is still in the same document, so focus can be placed in the popup's content without problem. It just happens that the content in a popup is displayed in a separate widget. The popup's widget never gets activated though.

When a child iframe exists in a popup, its content is in a different document and a different nsIDOMWindow. The events still fire on the parent window, as the popup is not activated.

As far as I've been able to tell, only widgets with nsIDOMWindows can be activated currently.

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Why can't we activate the child iframe? Or we could activate the popup if something in it gets focus?

Sorry if we're going in circles here, but really you know as much about this as I do, so you'll probably have to fix it.

Comment 25

[Neil Deakin]

(In reply to comment #24)
> Why can't we activate the child iframe? Or we could activate the popup if
> something in it gets focus?

The popup is a <menupopup>, yet the focus controller expects an nsIDOMWindow to be activated. I haven't been able to figure out why, but the OS only sends events to an activated window.
 
> Sorry if we're going in circles here, but really you know as much about this as
> I do, so you'll probably have to fix it.
> 

Sure, I don't really know much about this stuff either. I was hoping someone did ;)

Comment 26

[Neil Deakin]

(In reply to comment #24)
> Why can't we activate the child iframe? Or we could activate the popup if
> something in it gets focus?
> 

Actually, I have figured out how to activate the popup now. We just skip some window activating code in nsEventStateManager when receiving an NS_ACTIVATE event with a popup for its widget. Keyboard events then get fired at the right widget.

The issue with activating the popup, of course, is that the parent window becomes deactivated, dimming the titlebar.

Comment 27

[Dietrich Ayala (:dietrich)]

Are there fatal problems with this patch? It's blocking-, but if it's *better* than status quo, we should consider taking it, as it's blocking feature development on the front-end.

Comment 28

[Neil Deakin]

There isn't really a way to fix this without some disadvantage. On Windows, key events can't be fired at a window unless it's activated.

The patch in bug 390178 causes popups to be activated which fixes that bug as well as this one, but means that the focused window changes (the titlebar deactivates, and things that want the focus to remain on the main window like the customize toolbar require extra clicks)

The patch here fixes only this bug, and isn't really a good fix.

Comment 30

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Now that 390178 is fixed, this is fixed too right? Certainly the testcase works for me on Mac.

Comment 31

[Neil Deakin]

Bug 390178 couldn't have fixed this, as that was a Windows only change. The testcase still doesn't work for me.

Comment 32

[Robert O'Callahan (:roc) (email my personal email if necessary)]

You're right, I didn't test it properly.

Comment 35

[Neil Deakin]

This bug should have been fixed by 178324.

Comment 36

[Neil Deakin]

OK, this wasn't fixed after all.

Comment 40

[Alice0775 White]

WORKAROUND for thest case is here.

Tools > Options... > Content > Fonts & Colores Advanced... > 
Select a languages to add ... > Japanese [ja] > Add
Minimum Font Size 20 > OK > OK

OR

View > Zoom > Zoom Text Only
Ctrl + + (10 times and more)


Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100506 Minefield/3.7a5pre ID:20100506040636

Comment 41

[Brian Nicholson]

Reading some of these comments and seeing how long this bug has been open, I'm getting the impression that this issue may not be fixable.  Is this the case, or is this bug still being worked on?  We're trying to reuse our code between Google Chrome and Firefox, which we were hoping to do simply by having a popup panel containing an iframe containing a simple HTML file; however, this bug is clearly a dealbreaker.  I'd imagine that many developers would like to use this approach to simplify their extensions, considering how clean the Google Chrome model is.  Is there a simple way to do this that we are overlooking?

Comment 42

[Godmar Back]

I'd like to follow up on Brian's message. 

The inability to display HTML to the user from the XUL UI has become a major blocker for us. See Bug 561157.

If you've ever used a Google Chrome extension, you're familiar with its "browser actions" - that's exactly what we'd like to implement. It would be very, very unfortunate if this couldn't be implemented in Firefox. (Surprising, actually).

Ignoring the specifics of this particular bug, is there any way whatsoever to display HTML in a rectangular region that appears to the user as though it is part of the browser's UI?

 - Godmar

(*) See https://chrome.google.com/extensions/img/naenffbbmemiekgcjgelmggkaohdeaab/1277978726.22/screenshot_big/11001 and https://chrome.google.com/extensions/img/pgphcomnlaojlmmcjmiddhdapjpbgeoc/1277231524.42/screenshot/5001 for just two examples.

Comment 43

[Robert O'Callahan (:roc) (email my personal email if necessary)]

There are many ways to display HTML in a XUL UI:
1) including HTML inline in the XUL document. This should work fine everywhere, including in panels.
2) include an HTML IFRAME in the XUL document. This currently works fine everywhere, except that IF the iframe is in a panel, there are some problems with focus. This bug is about that one issue.
3) instead of a panel, you can create a XUL window using window.open that contains HTML inline or in an IFRAME, and everything should work.

Having said that, if I open this bug's testcase in a Firefox trunk build, I *can* tab into the textbox and type into it, so it looks like focus is basically working now? The problem is that I can't focus the textbox by clicking on it. In fact, if you click on the arrow to do a search, you navigate to a new page where there is a textbox that you *can* click to focus.

So I think we have here just some simple bug that's preventing click-to-focus from working, sometimes. Enn, can you look into that?

Comment 44

[Timothy Nikkel (:tnikkel)]

Some of the links on the page in the panel can be clicked, but some of them cannot be clicked I think a reduced testcase would help here.

Comment 45

[Alice0775 White]

In testcase, I can click at the right-side(but inside) of textbox and can input text.
A coordinate and the mouse pointer of textbox element seem to shift?

Comment 46

[Godmar Back]

Thank you for your reply.

We considered options 1) and 3) and rejected them. Option 1 means that we need to use XHTML, and libraries such as jQuery will not work or would require substantial adaptations. Also, in this case, we would be sharing the JavaScript global scope with the embedding XUL document.  Recall that our goal - which we believe to be a reasonable one - is to reuse design elements and JavaScript code designed for a regular client-side page (just like we are able to do in Google Chrome browser action page.)

Brian prototyped Option 3 as well and we looked at it earlier this afternoon, but it makes for a less than optimal user experience - the window looks like a new top-level window, with 'fat' decorations that can't be removed - not as sleek as a Google Chrome browser action; and, importantly, not like a window that visually belongs to the parent window that created it.

That leaves Option 2, which is prevented by this bug. Also, we need something that works in Firefox 3.6.* as deployed - a solution that only works in Firefox 4 (I'm not sure if 'trunk' means the 3.6 or the 4 development line) will be out of our timeframe.

I should point out that if we implement it straightforwardly (a panel that embeds an iframe and which is linked via 'popup' to a toolbar button), the behavior of the resulting system is flaky, to say the least. The very first time you open the popup panel, focus is retained. The second time, it is lost. Sometimes, it is possible to click on an area in the iframe that is not a textbox and regain focus. Not always, though, and after you click a few times, it will reliably not work. Eventually, the blinking caret that marks the cursor in textboxes will disappear (and won't be visible even when the user clicks on say the URL address bar.)  So - whatever bug there is in  how Firefox manages focus seems state-dependent and it affects the entire window.

Are there any viable options to display HTML in a way that integrates with the browser's UI?

Comment 47

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #46)
> Brian prototyped Option 3 as well and we looked at it earlier this afternoon,
> but it makes for a less than optimal user experience - the window looks like a
> new top-level window, with 'fat' decorations that can't be removed - not as
> sleek as a Google Chrome browser action; and, importantly, not like a window
> that visually belongs to the parent window that created it.

You can make the window decorations go away with hidechrome. You can also make the window transparent, so it effectively takes any shape and look you want.

> That leaves Option 2, which is prevented by this bug. Also, we need something
> that works in Firefox 3.6.* as deployed - a solution that only works in
> Firefox 4 (I'm not sure if 'trunk' means the 3.6 or the 4 development line)
> will be out of our timeframe.

Trunk means Firefox 4. If we have a solution that works on trunk but not 3.6, we might possibily be able to backport fixes to make it work on 3.6 too. No guarantees.

> I should point out that if we implement it straightforwardly (a panel that
> embeds an iframe and which is linked via 'popup' to a toolbar button), the
> behavior of the resulting system is flaky, to say the least. The very first
> time you open the popup panel, focus is retained. The second time, it is lost.
> Sometimes, it is possible to click on an area in the iframe that is not a
> textbox and regain focus. Not always, though, and after you click a few times,
> it will reliably not work. Eventually, the blinking caret that marks the
> cursor in textboxes will disappear (and won't be visible even when the user
> clicks on say the URL address bar.)  So - whatever bug there is in  how
> Firefox manages focus seems state-dependent and it affects the entire window.

That could be the bug(s) mentioned in comment #43 and #44, or it could be something else.

> Are there any viable options to display HTML in a way that integrates with the
> browser's UI?

Yes, and I listed them. Your question is specifically "are there any viable options to display focusable content in an HTML IFRAME in a XUL panel in Firefox 3.6"? and the answer is currently, unfortunately, no. But if we find the bug(s) that are present on trunk, maybe we could backport the fix(es).

Comment 48

[Godmar Back]

ps: I just wanted to confirm that opening a separate top-level window with the 'hidechrome' attribute works.  I'm not sure why the awkward work-around was suggested in Bug 561157.  We wish we had known about hidechrome earlier.

We now use window.open with hidechrome on Windows. On Linux, it has positioning issues - but Linux doesn't exhibit the bug discussed here, so we use an iframe in a panel on Linux.

Comment 50

[Neil Deakin]

The main issue has always been that we only handle focus being in a document, and a popup has a different top-level native widget than the document it is in. Confusion arises when trying to focus a child document in a window the OS doesn't think is active.

This bug is actually a number of related issues, different on each platform. Some issues only appear with certain flags (noautohide, etc). It would likely be better to file specific bugs on each issue.

However, a number of improvements have been made to gtk window/focus handling that have likely affected this bug and I notice some improvements on Windows over https://wiki.mozilla.org/XUL:Panel_Improvements from recent testing. Various bugs might have improved things (draw on titlebar, bugs related to widget removing)

Comment 51

[ArtworkAD]

Is there any progression made till now? I have the same problem.

<popupset id="mainPopupSet">
    <menupopup id="smsflatrate-popup">
	<iframe height="500px" src="http://webapp.mysitee.net" flex="1" 
       type="content-primary"/>							
    </menupopup>	
</popupset>

When I open the popup the main navigation bar of firefox gets dimmed and I can not focus input elements in the external resource that I include using iframe.

Is there any workaround for that problem? At least it works for me using a sidebar.

Comment 52

[Neil Deakin]

Numerous changes have occurred that would likely have had an impact on this bug have occurred over the last year. Testing of various popups and testcases on each platform shows that this bug and the issues described on https://wiki.mozilla.org/XUL:Panel_Improvements are no longer present, except for some minor incorrect mouse-raise-and-click behaviour.

I'm thus going to close this bug. If specific issues are found please attach clear testcases or open other bugs.