Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080928084201 Minefield/3.1b1pre Confirmed with latest trunk on Windows XP.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
This regressed on 3 July 2007 probably from Bug 238987.
Component: Tabbed Browser → DOM: Events
Product: Firefox → Core
QA Contact: tabbed.browser → events
Created attachment 340949 [details] testcase Note, blur and focus don't bubble per DOM Events spec. Bug 238987 just revealed a bug that we don't always dispatch the blur event to |window|, only to |document|. But that bug was there already in 1.8 (FF2).
For some reason this wasn't implemented in bug 27936 (yes, that is ~8 years ago). http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/events/src/nsEventStateManager.cpp&rev=1.439&mark=436#416
Created attachment 340957 [details] [diff] [review] possible patch Changing focus/blur handling is always regression-risky. I think the patch does what I'd like to see happening, but something may rely on the old behavior. Needs lots of testing.
Created attachment 340993 [details] [diff] [review] passes mochitest, chrome and browser-chrome I still need to write testcases for this
Attachment #340957 - Attachment is obsolete: true
Comment on attachment 340993 [details] [diff] [review] passes mochitest, chrome and browser-chrome Doesn't regress bug 200735, bug 203117, bug 194104 nor bug 201996. (bryner fixed those bugs when modifying this code.) Still need to write mochitests
Smaug, how risky do you think this is? Do you think you could get the tests written in time for 1.9.1? If so, it'd be awesome to get this in if we feel comfortable about this patch...
Assignee: nobody → Olli.Pettay
Priority: -- → P1
Changing focus handling is always a bit risky. The current code is clearly wrong, there is even the XXX comment. I'll try to write the mochitest ASAP.
10 years ago
Created attachment 350001 [details] [diff] [review] with mochitesttest Sorry, my asap wasn't really asap.
Comment on attachment 350001 [details] [diff] [review] with mochitesttest Looks good to me. r+sr=jst
10 years ago
Attachment #350001 - Flags: approval1.9.1?
Comment on attachment 350001 [details] [diff] [review] with mochitesttest If we want this for 1.9.1, this should land asap to get testing.
Comment on attachment 350001 [details] [diff] [review] with mochitesttest a191=beltzner
Attachment #350001 - Flags: approval1.9.1? → approval1.9.1+
10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Fixed on trunk and 1.9.1
I disabled the test on 1.9.1 for now because SM is also running mochitest and the test relies on FF's new-window handling.
(In reply to comment #15) See bug 457672.
Target Milestone: --- → mozilla1.9.1b3
will look at a patch approval if you feel strongly about getting this into a 3.0.x release (and think the patch is safe enough), but not "wanted" in the sense of "release-drivers need to make sure this gets in sometime".
verified FIXED on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090331 Minefield/3.6a1pre and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090401 Shiretoko/3.5b4pre
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
You need to log in before you can comment on or make changes to this bug.