392148 - Blur event not fired anymore on window after iframe.contentWindow.focus and window.focus

Status: RESOLVED INVALID

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

Description

[Martijn Wargers (dead)]

Attachment: testcase

See testcase, you should get an alert with the text "blur", but that's not happening on current windows trunk builds anymore.
This regressed between 2007-06-16 and 2007-06-17:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-06-16+04&maxdate=2007-06-17+07&cvsroot=%2Fcvsroot
It seems like the backout of the patch for bug 261074 has caused this somehow.

I also tested with a build before the patch for bug 261074 was checked in, but there the alert comes up fine (and crashes the browser, that was bug 339470).

Comment 1

[Ere Maijala (slow)]

The reported problem will be fixed with correction to the backout in bug 261074. There's another issue though that needs to be checked out. It might be more related to mouse trailer or something, but focusing another window after having focus in the iframe will wreak havoc.

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Ere, what's the status here? This would be great to get fixed for 1.9. Do you have time to look at this if this wasn't fixed by the fix for bug 261074?

Comment 3

[Ere Maijala (slow)]

The originally reported bug should be fixed by the completed backout in bug 261074, but the other issue is that if you make the blur event fire by clicking another window you enter an endless loop of popups. I'm intending to check it but been on a work trip this week (might be able to work on it next weekend). 

Comment 4

[Ere Maijala (slow)]

The remaining issue isn't a mousetrailer problem after all, but seems to be something going very wrong in focus handling. Also the following assertion is posted indicating that something's getting badly confused:

###!!! ASSERTION: Attempt to decrement focus controller's suppression when no suppression active!

I will try to find out the reason for this as well as try to continue working on bug 261074, but I need to familiarize myself more with the event state manager and focus controller, so I'm afraid I can't provide a quick solution. Any help won't be turned down.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

I marked this security-sensitive because of bug 210240 comment 12.

Comment 6

[Ere Maijala (slow)]

Ok, let's continue in bug 210240. The original problem is fixed anyway and bug 210240 suits the followup better.

Comment 7

[Martijn Wargers (dead)]

I'm confused, this is definitely not worksforme for me.
With the testcase, I attached in this bug, I get a 'blur' alert on branch, but not using current trunk:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007093005 Minefield/3.0a9pre

Ere, are you getting the blur alert on trunk?

Comment 8

[Ere Maijala (slow)]

I thought the original issue was fixed with the fix for the backout of bug 261074, and indeed I'm getting blur events as they cause the other problem. Or am I missing something?

Comment 9

[Ere Maijala (slow)]

From irc: the blur should have fired automatically when loading the test case. I didn't realise that. The problem still exists and I'll try to see what's causing it.

Comment 10

[Ere Maijala (slow)]

Weird thing: the blur fires just fine for the iframe content window if you add an input element and focus it instead of window.

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Ere, are you going to be able to get to this soon-ish? We should probably get this in pretty quickly if we want it fixed since focus changes are always scary.

Comment 12

[Ere Maijala (slow)]

I've been working on this for quite a while, but not there yet. The focus stuff is so complicated and difficult to debug. If I find the right place soon, it _could_ be an easy fix, but it seems any change in focus stuff is risky and might have unexpected consequences.

Comment 13

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Given that bug 261074 is fully backed out now, is this really a regression? If it's not I think this might not be a blocker. I'm getting really worried about taking focus changes at this point.

Comment 14

[Mike Schroepfer]

(In reply to comment #13)
> Given that bug 261074 is fully backed out now, is this really a regression? If
> it's not I think this might not be a blocker. I'm getting really worried about
> taking focus changes at this point.
> 

Given this comment moving to wanted list.  Re-nom if there is new info

Comment 15

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Also removing 'regression'. Please readd if this really is a regression despite comment 13

Comment 16

[Ere Maijala (slow)]

It *is* a regression, unless disabling onblur of iframe's contentWindow is intentional.

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

could you describe the actual regression then, this bug is very confusing at this point. Is the testcase good, i.e. does it show the regressions? Do we know what caused the regression or when this regressed?

Comment 18

[Ere Maijala (slow)]

Attachment: Impossible patch

Something like this could fix it. This, though, will cause an endless alert loop, so we probably don't want it as it. 

Sicking: see the first comment. Later comments are at least partly my confusion..

Comment 19

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Even the first comment points to the partial backout which is fixed now :(

So I take it your patch does not restore behavior to how FF2 behaved?

Sorry, I'm still very confused by what is going on here. It does seem like it makes sense that alerts firing from blur/focus events can lead to infinite loops. That doesn't seem like a bug in itself to me. Unless it's something that sites usually do and that didn't used to cause infinite loops.

Comment 20

[Ere Maijala (slow)]

Oops, see description, not the first comment..

The bug causing the loop is bug 112294, which is also work in progress. I'd say this cannot be checked in until I (or someone else) have managed to fix 112294 properly.

Comment 21

[Ere Maijala (slow)]

Okay, with bug 112294 properly fixed there shouldn't be any problem here after all. Sorry about the confusion. Closing.