Closed
Bug 616832
Opened 14 years ago
Closed 14 years ago
Focus in limbo after closing a tab-modal prompt
Categories
(Toolkit :: General, defect)
Toolkit
General
Tracking
()
RESOLVED
DUPLICATE
of bug 617507
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: dot_ulli, Unassigned)
References
()
Details
(Keywords: regression)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101204 Firefox/4.0b8pre Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101204 Firefox/4.0b8pre The actual tab looses the focus after an alert is shown, so the normal navigation via key [Up], [Down], etc., etc., shows no effect. The action taken on the alert doesn't matter. Reproducible: Always Steps to Reproduce: 1. open a page showing an alert 2. perform any action an the alert 3. the alert is closed and the normal tab is displayed Actual Results: Now you can't navigate with the regular keys within the tab. Expected Results: A normal navigation should be reestablished.
I can't read this site, but it's a good testcase. http://www.lakbima.lk/ A right click shows a silly alert, click ok and press [esc] to exit the fx popup. Now you can scroll using the mouse, but not with the keys mentioned above.
Comment 2•14 years ago
|
||
Seeing this too on Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20101217 Firefox/4.0b9pre ID:20101217030324. A Mitigation is regaining the Focus by clicking on an other Site Element or e.g. Tab + switch back - if you don't have to rely on Keyboard-only Navigation. Not sure if this Accessibility/Focus Issue justifies Blocking State. Maybe Bug 617507 is related, though filed against MacOS.
Blocks: 59314
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Component: Keyboard Navigation → General
Ever confirmed: true
Keywords: regression
OS: Linux → All
Product: Firefox → Toolkit
QA Contact: keyboard.navigation → general
Updated•14 years ago
|
Summary: Broken navigation keys after landing of Bug 59314 → Focus in limbo after closing a tab-modal prompt
Updated•14 years ago
|
Hardware: x86_64 → All
I've to reset the blocking question. Our opinions may differ, but this doesn't matter. On this silly site the decision may be right, every normal user surely knows about to regain the focus. Seems to be a documented feature, if you loose the focus then you have to try ... The same procedure, now working with 'phpMyAdmin', are you really sure about any possible effects when you click inside the window ? The first click really doesn't activate a given delete action ? I am not.
blocking2.0: - → ?
Comment 5•14 years ago
|
||
(In reply to comment #4) > The same procedure, now working with 'phpMyAdmin', are you really sure about > any possible effects when you click inside the window ? The first click really > doesn't activate a given delete action ? I think if you are trying to regain focus and you do so by trying to click on the delete button in something like phpMyAdmin then you shouldn't be playing with phpMyAdmin, it will delete your stuff regardless of whether the content window has focus or not. That it comes after a tab-modal prompt is only tangentially related
blocking2.0: ? → -
Don't want to waste your time. The aspect wasn't trying to hit the delete key. The aspect was the accidental but unnoticed hit of a delete check mark. At the prompt, are you really sure ... you can't distinguish between any and any+1 deletions.
Updated•14 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•