The default bug view has changed. See this FAQ.

Cannot type into an editor in a xul panel

RESOLVED FIXED

Status

()

Core
XUL
RESOLVED FIXED
10 years ago
6 years ago

People

(Reporter: mano, Assigned: Neil Deakin)

Tracking

(Blocks: 1 bug)

unspecified
Points:
---
Dependency tree / graph
Bug Flags:
wanted-next +
blocking1.9 -
wanted1.9 -

Firefox Tracking Flags

(blocking2.0 -)

Details

Attachments

(2 attachments)

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.
Flags: blocking1.9?
This is even worse on windows, just focusing the editor closes the panel.
OS: Mac OS X → All
Hardware: PC → All
(Assignee)

Comment 2

10 years ago
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
Blocks: 387485
roc and I aren't the right people to triage the blocking1.9? flag here.  Not sure how to fix that...
(Assignee)

Comment 4

10 years ago
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.

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

Updated

10 years ago
Depends on: 390197
(Assignee)

Comment 6

10 years ago
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.
Depends on: 130078
(Assignee)

Comment 7

10 years ago
Created attachment 274673 [details] [diff] [review]
redirect key event if the focus is in a subshell
Assignee: jag → enndeakin
Status: NEW → ASSIGNED
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
(Assignee)

Updated

10 years ago
Attachment #274673 - Flags: superreview?(roc)
Attachment #274673 - Flags: review?(Olli.Pettay)
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?
(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

(Assignee)

Comment 10

10 years ago
Created attachment 275971 [details]
testcase

Olli, this is a testcase for this bug. The patch in bug 130078 is also needed to get mouse events to work.
+          // 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?
(Assignee)

Comment 12

10 years ago
(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.
popups capture mouse events, but IMHO key events should still go wherever the focus is.
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 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-/+
(In reply to comment #13)
> popups capture mouse events, but IMHO key events should still go wherever the
> focus is.
> 

I agree with this.
(Assignee)

Comment 17

10 years ago
(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?

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

Comment 19

10 years ago
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.
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?
(Assignee)

Comment 21

10 years ago
(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?

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

Comment 23

10 years ago
(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.
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.
(Assignee)

Comment 25

10 years ago
(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 ;)
(Assignee)

Comment 26

10 years ago
(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.
(Assignee)

Updated

10 years ago
Depends on: 395670
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
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.
(Assignee)

Comment 28

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

(Assignee)

Updated

9 years ago
Duplicate of this bug: 425795
Attachment #274673 - Flags: superreview?(roc)
Attachment #274673 - Flags: review?(Olli.Pettay)
Now that 390178 is fixed, this is fixed too right? Certainly the testcase works for me on Mac.
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+
(Assignee)

Comment 31

9 years ago
Bug 390178 couldn't have fixed this, as that was a Windows only change. The testcase still doesn't work for me.
You're right, I didn't test it properly.
(Assignee)

Updated

9 years ago
Duplicate of this bug: 448981
(Assignee)

Updated

9 years ago
Duplicate of this bug: 448983
(Assignee)

Updated

8 years ago
Depends on: 178324
No longer depends on: 130078
(Assignee)

Comment 35

8 years ago
This bug should have been fixed by 178324.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Assignee)

Comment 36

8 years ago
OK, this wasn't fixed after all.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Updated

7 years ago
Duplicate of this bug: 526603
(Assignee)

Updated

7 years ago
Duplicate of this bug: 543771
(Assignee)

Updated

7 years ago
Duplicate of this bug: 561157

Comment 40

7 years ago
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

7 years ago
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

7 years ago
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.
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?
blocking2.0: --- → ?
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

7 years ago
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

7 years ago
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?
(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

7 years ago
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.
(Assignee)

Updated

7 years ago
Duplicate of this bug: 579291
blocking2.0: ? → -
(Assignee)

Comment 50

7 years ago
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

6 years ago
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.
(Assignee)

Comment 52

6 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.