Closed Bug 616832 Opened 14 years ago Closed 14 years ago

Focus in limbo after closing a tab-modal prompt

Categories

(Toolkit :: General, defect)

defect
Not set
major

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.
Version: unspecified → Trunk
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
Summary: Broken navigation keys after landing of Bug 59314 → Focus in limbo after closing a tab-modal prompt
Hardware: x86_64 → All
You can get focus back so I don't think this blocks.
blocking2.0: ? → -
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: - → ?
(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.
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.