Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090228 Minefield/3.2a1pre Steps to reproduce: 1. Make sure you have two tabs open. 2. Make sure focus is on the page (not the address bar). 3. Press Cmd+Shift+D or select "Bookmark All Tabs..." from the Bookmarks menu. 4. Press Esc or click Cancel. Result: The Firefox window goes from dark gray to light gray (indicating that it has lost focus). Clicking does not restore focus completely. Have to Cmd+Tab to recover.
I think this is the same as bug 480768, feel free to dupe either way... (note this happens on 1.9.1 as well).
I dunno. I can't reproduce that one, and it doesn't really sound the same.
The underlying problem is the same, the focus isn't being taken away/restored from the parent window appropriately, the gray menu text is for windows only, mac doesn't have that (afaik). Can you confirm the problem is in 3.1 as well?
Yes, the mentioned "bookmark all tabs" dialog is also a modal one. Due to we have more information in bug 480768 we should dupe this one against bug 480768.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 480768
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I think this isn't actually the same problem as bug 480768. I have a patch for this one, but it may not fix bug 480768 - waiting tryserver builds to test.
This is a different approach to focus handling. Allow NS_GOT/LOSTFOCUS and NS_ACTIVATE/DEACTIVATE to propagate to event state manager, but don't dispatch focus/blur events. The change to nsGlobalWindow isn't actually needed, but reduces the risk for regressions, since event suppression is used then only when there is sync XHR in the stack. This fixes also bug 480768. https://build.mozilla.org/tryserver-builds/2009-03-01_12:firstname.lastname@example.org_suppress_widget_events_and_suppress_only_when_needed/
Olli, I can see similar things on OS X and Windows when opening a new tab. Especially on OS X the whole application lose its focus. I have to switch to another application and back to get the focus back. This happens sporadically. Is it worth trying the build above to check? Could you please adjust the product/component so we have the right one?
Status: REOPENED → ASSIGNED
OS: Mac OS X → All
Hardware: x86 → All
Marking this a P1 blocker, as it's a regression from P1 blocker bug 333198, we don't want one w/o the other.
Flags: blocking-firefox3.2? → blocking-firefox3.2+
Priority: -- → P1
Target Milestone: --- → Firefox 3.1b3
Component: Bookmarks & History → Event Handling
Product: Firefox → Core
QA Contact: bookmarks → events
Target Milestone: Firefox 3.1b3 → ---
(In reply to comment #9) > Is it worth trying the build above to check? Yes! > Could you please adjust the product/component so we have the right one? Done.
Target Milestone: --- → mozilla1.9.1b3
Flags: blocking1.9.2? → blocking1.9.2+
Flags: blocking1.9.2+ → blocking1.9.1+
Status: ASSIGNED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
Verified fixed on trunk and 1.9.1 with builds on OS X and Windows: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090304 Minefield/3.2a1pre Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090304 Shiretoko/3.1b3pre ID:20090304022008
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.