Closed Bug 613748 Opened 11 years ago Closed 11 years ago

Keyboard inputs do not work when tab-modal alerts are open in another tab


(Core :: DOM: UI Events & Focus Handling, defect)

Not set



Tracking Status
blocking2.0 --- beta8+


(Reporter: josh.tumath+bugzilla, Assigned: enndeakin)





(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101120 Firefox/4.0b8pre
Build Identifier: 

Keyboard inputs do not work when tab-model alerts are open in another tab.

Reproducible: Always
Blocks: 59314
blocking2.0: --- → ?
Version: unspecified → Trunk
Cannot reproduce on Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101120 Firefox/4.0b8pre.

If I run "javascript:alert(1)" on homepage and do not discard it, I can still write in here.
Then maybe this bug has a more specific problem. Here is how to reproduce it:-

1. Open
2. When the test completes, click on "A" to open the alert.
3. Go to the tab with this bugzilla page in it, and try to type in the comments textarea.
Confirming with the Acid3 testcase.
Attached file Testcase
As seen in this testcase the bug does not occur when using a link (<a>), but does occur when using a <h1> or any other element I have tested.
Ever confirmed: true
Duplicate of this bug: 613768
Eww. We should probably fix this for beta 8.
blocking2.0: ? → beta8+
Summary: Keyboard inputs do not work when tab-model alerts are open in another tab → Keyboard inputs do not work when tab-modal alerts are open in another tab
OS: Windows 7 → All
Hardware: x86_64 → All
Seems like the alert needs to come from an onclick handler and not just a plain alert:


data:text/html,<p onclick="alert(0)">Foo</p>


Something interesting I noticed when clicking on Bugzilla's URL data URI warning..

Fails with href:

data:text/html,<a onclick="confirm(0)">Foo</a>

Happens to work when there's no href (like with bugzilla):

data:text/html,<a href="/" onclick="confirm(0)">Foo</a>
What is happening is that nsPresShell::sDontRetargetEvents is being set (to prevent recursion) but it isn't being cleared until after the modal prompt closes
thus, events don't get retargeted to the right focused window.

This should be changed to use an argument instead of a global flag.
Attached patch Patch, not extensively tested (obsolete) — Splinter Review
Let's try out this patch to see if it fixes some issues.
Assignee: nobody → enndeakin
Attached patch Patch v.2Splinter Review
Oops, Enn's patch needed one obvious change to nsDOMWindowUtils.cpp to compile. But WFM with the testcase here.
Attachment #492440 - Attachment is obsolete: true
Component: General → Event Handling
Product: Toolkit → Core
QA Contact: general → events
Comment on attachment 492469 [details] [diff] [review]
Patch v.2

bz suggested smaug would be best to look at this. FWIW, I pushed this to try, seems to be doing fine there.

Also noted that this changes a (native) API, so I'll email drivers. Seems like this should ok, it's a big win (tab-modal prompts), and should only potentially effect binary addons (and the fix for them is easy).
Attachment #492469 - Flags: review?(Olli.Pettay)
Attachment #492469 - Flags: review?(Olli.Pettay) → review+
Whiteboard: [has patch][has review]
Sent email to releave-drivers for approval of the interface change, a=bsmedberg.

Thanks Enn!
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][has review]
Target Milestone: --- → mozilla2.0b8
Depends on: 1052343
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.