Closed Bug 307153 Opened 15 years ago Closed 15 years ago

since 20050817: After closing a modal-dialog, focus isn't restored to the right element

Categories

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

1.8 Branch
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla1.8beta4

People

(Reporter: mano, Assigned: aaronlev)

References

Details

(Keywords: access, regression, verified1.8)

Attachments

(1 file)

Regression: In the bookmarks manager, after closing a sub-(modal?)-dialog, focus
isn't restored to the right element,  the result is a unresponsive toolbar
button set.

STR:
 1. Open BM, choose an item in the right three.
 2. Click Properties.
 3. Click Ok.

  --> The toolbar buttons do nothing unless you refocus the right tree.
Actually, this is larger problem, try this in a browser window:
1. Focus the content area
2. Open the about dialog (Windows/Linux) or the Add Bookmark Dialog (mac).
3. Close it

--> The content area isn't focused (arrow keys, etc. don't work).
Flags: blocking1.8b4?
Summary: Regression: In the bookmarks manager, focus isn't restored after closing a sub-dialog → Regression: After closing a modal-dialog, focus isn't restored to the right element
Confirmed regression using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050904
Firefox/1.0+
OS: MacOS X → All
Hardware: Macintosh → All
can you guys put together a regression window on this for us? 
WFM in:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050816
Firefox/1.0+

Broken in:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050817
Firefox/1.0+
Summary: Regression: After closing a modal-dialog, focus isn't restored to the right element → since 20050817: After closing a modal-dialog, focus isn't restored to the right element
Assignee: nobody → aaronleventhal
Blocks: 258285
Component: Bookmarks → Event Handling
Product: Firefox → Core
Target Milestone: --- → mozilla1.8beta4
Version: 1.5 Branch → 1.8 Branch
Confirming this regression is from bug 258285, specifically it's from the
"Window Switch" focus suppressions that was removed. I have updated my patch
in bug 306076 to address this issue as well (i.e. bring them back, but add a
matching unsuppress).
Assignee: aaronleventhal → mats.palmgren
Depends on: 306076
I have a fix for this which is not risky. It leaves in the original code but
adds a couple of null window checks. The null windows were causing the focus
suppression to misfire. So it fixes this bug without regressing any of the
testcase from the fix for bug 258285.
Assignee: mats.palmgren → aaronleventhal
Comment on attachment 195018 [details] [diff] [review]
Reverse part of bug 258153, but add null checks so that it doesn't misfire when there is no window yet during tab switching

Looks ok, but can you fix the spelling of "suppress" in the comment while
you're here?
Attachment #195018 - Flags: superreview?(bryner) → superreview+
Flags: blocking1.8b4? → blocking1.8b4+
Comment on attachment 195018 [details] [diff] [review]
Reverse part of bug 258153, but add null checks so that it doesn't misfire when there is no window yet during tab switching

a=schrep - per phone discussion fix is low-risk and critical - land on branch
and trunk
Attachment #195018 - Flags: approval1.8b4+
Attachment #195018 - Flags: review?(mats.palmgren) → review+
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
verified on:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050906
Firefox/1.4
Keywords: fixed1.8verified1.8
Depends on: 312227
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.