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.
This is even worse on windows, just focusing the editor closes the panel.
OS: Mac OS X → All
Hardware: PC → All
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
12 years ago
roc and I aren't the right people to triage the blocking1.9? flag here. Not sure how to fix that...
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?
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: jag → enndeakin
Status: NEW → ASSIGNED
12 years ago
Flags: blocking1.9? → blocking1.9-
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
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?
(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.
(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?
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?
(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.
(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.
(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 ;)
(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.
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.
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.
Now that 390178 is fixed, this is fixed too right? Certainly the testcase works for me on Mac.
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.
This bug should have been fixed by 178324.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
OK, this wasn't fixed after all.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
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?
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.
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?
(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).
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.
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)
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.
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: 10 years ago → 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.