Initial focus handling is broken with Qt

RESOLVED FIXED

Status

RESOLVED FIXED
9 years ago
2 years ago

People

(Reporter: steffen.imhof, Assigned: steffen.imhof)

Tracking

Trunk
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

9 years ago
Example:
  Start Firefox
  Click into URL Bar
  -> the bar does not get the focus, it is not possible to type anything

  Click into webpage area
  Click into URL bar
  -> now the bar has the focus and it is possible to enter a URL
(Assignee)

Comment 1

9 years ago
Created attachment 427789 [details] [diff] [review]
Move decision about what QGraphicsItems are focusable to nsWindow

This seems to be related to the fact that every MozQWidget is deemed focusable in its constructor.

The attached patch removes the flags from MozQWidgets constructor and instead sets them after nsWindow's creation of the MozQWidget object, but only for child windows/paintareas.

Also removed is the whole sceneEvent() method which had some code in it that was modelled after the fix for a similar problem with pure QWidgets.
Attachment #427789 - Flags: review?
Attachment #427789 - Flags: review? → review?(dougt)

Comment 2

9 years ago
steffen, what about other window types:

http://mxr.mozilla.org/mozilla-central/source/widget/public/nsWidgetInitData.h#49

for example, the window caused by the javascript window.prompt() will bring up a window with an edit box.  Will that be focusable.  (I don't recall if the edit box is the child which will get focus here, if if you need to focus the dialog itself).

Updated

9 years ago
Assignee: nobody → steffen.imhof
(Assignee)

Comment 3

9 years ago
Created attachment 428461 [details] [diff] [review]
Updated patch to fix the focus handling

Interestingly, the JS popup case did not work with or without the patch. But the investigation revealed a few problems, so here is the updated patch that should do everything.

In addition to making only child (and plugin) windows focusable, the activation handling is also moved to the hopefully right place by grabbing the events on the MozQGraphicsView and triggering Mozilla's Dispatch(De)ActiveEvent on nsWindow via MozQWidget so that Mozilla's internal focus is also set correctly.

This works for me in Qt Fennec and Firefox builds. I'm not 100% sure about all corner cases but from what I can see it's definitely an improvement.
Attachment #427789 - Attachment is obsolete: true
Attachment #428461 - Flags: review?
Attachment #427789 - Flags: review?(dougt)
steffen, please make sure that your review request assigned to some persone, not just "review?"
(Assignee)

Comment 5

9 years ago
Comment on attachment 428461 [details] [diff] [review]
Updated patch to fix the focus handling

Strange, I was quite sure I put Doug as the reviewer?!
Attachment #428461 - Flags: review? → review?(dougt)
(Assignee)

Comment 6

9 years ago
Created attachment 428740 [details] [diff] [review]
Update patch to fix focus handling

Added a small fix to SetFocus() when a raise is needed.
Attachment #428461 - Attachment is obsolete: true
Attachment #428740 - Flags: review?(dougt)
Attachment #428461 - Flags: review?(dougt)

Comment 7

9 years ago
Comment on attachment 428740 [details] [diff] [review]
Update patch to fix focus handling

http://hg.mozilla.org/mozilla-central/rev/e0819ee45f5b3b
Attachment #428740 - Flags: review?(dougt) → review+

Comment 8

9 years ago
Thanks Steffen.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.