311683 - Duelling windows

Status: RESOLVED FIXED

(Camino Graveyard :: Plug-ins, defect, P1)

Description

[dave oshel]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006 Camino/1.0a1+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006 Camino/1.0a1+

Watch two windows alternately jump to the foreground in an infinite loop!

Reproducible: Didn't try

Steps to Reproduce:
1. Open Camino and go to a page that links to other pages
2. Open NetNewsWire and find a feed item that links to a web page with embedded
Quicktime
3. Click on the link in NetNewsWire (Camino loads page with embedded QT)
4. Click on another link in the already Camino page
5. The two links enter an infinite loop as each attempts to grab the foremost
window position.
Actual Results:  
Useless duelling windows.

Expected Results:  
The last link clicked should have taken the foremost position.

Comment 1

[Torben]

I just had this happening with gmail and b.m.o (build 2005100604 (v1.0a1+)).
I'll never seen something like this before, so I guess it is a recent regression.

Comment 2

[Torben]

Possible test case:
http://secunia.com/multiple_browsers_dialog_origin_vulnerability_test/ 
Click on the "Test Now - Left Click On This Link" link.

I'll try to get time to find the regression window later this week.

Comment 3

[Jasper]

I just experienced the same thing on nos.nl a news website. A popup opened which
had real content playing. I hid the source window and then all heel broke loose.
Both where going from fornt to back like mad untill I close one of them. Yikes.

Comment 4

[JK]

I've done some research today using G4 optimized builds. What I found using the
above Secunia's page:

- 09-28 (krmathis' build): works fine.
- 09-29 (???): could not find an optimized build to download and test.
- 09-30~10-05 (wrc_fan's builds): it seems to work fine, but Camino crashes
after the second OK is clicked. 09-30 is the first build that fixes the "blank
page after Camino is unhide" bug.
- 10-06 (wrc_fan's build): first build with the blinking windows, and the first
build after the bug "no focus in pop-up window" was fixed.

So it seems that the blinking windows bug is related to both fixes. I just need
a 09-29 build to confirm this a priori. I hope this helps.

Cheers

Comment 5

[Mike Pinkerton (not reading bugmail)]

could this be fallout from the focus/activation changes for the blank window?

Comment 6

[Simon Fraser [no longer active]]

Quite possibly, yes. A solid testcase would be good.

Comment 7

[JK]

Sorry for reporting using non official builds. I got the official nightlies link
from Samuel Sidler in Mozillazine:
<http://mozilla.isc.org/pub/mozilla.org/camino/nightly/>.

The results are almost the same: the 09-29 build works fine, but I could not
find the 10-06 build, and the 10-07 build shows the blinking windows.

Cheers

Comment 8

[Kevin Parichan]

This looks like a bug I was about to report.

Create a blank .html file on the desktop.
Drag it onto the Camino icon to open it.
Now repeat that last step, attempting to open the document again.
You get what appears to be the "dueling windows" effect.

However, in this case, Camino should be smart enough to know that that document
is already open and not attempt to open another one.

Comment 9

[Simon Fraser [no longer active]]

Yeah, I think this was me.

Comment 10

[Simon Fraser [no longer active]]

Here's what's happening:
1. Camino has a window open, with the content view focussed, but is not the
frontmost app.
2. You drag a file onto Camino's icon. That old window gets a
-makeKeyAndOrderFront, and the code down in widget queues up a
-performSelector:afterDelay to fire off focus/activate events.
3. Camino makes a new window for the file, in the front, which involves making
it key. This queues up a call to activate the browser.
4. On the next event cycle, the widget code fires off the activate/focus events,
focussing the _old_ window (this bubbles up into Camino, which does a
-makeKeyAndOrderFront, since that window is no longer frontmost).
5. Then the delayed activate happens, notices its window is no longer frontmost,
and fires a -makeKeyAndOrderFront;
6. Lather, rinse, repeat.

It seems like the delayed activate stuff from bug 297343 is gonna cause these
kinds of problems. I may have to use another technique to fix that bug (probably
involving -setSuppressMakeKeyFront:).

Comment 11

[Simon Fraser [no longer active]]

Attachment: Patch

This patch undoes the delayed selectdor stuff that the patch for bug 297343
added, and instead fixes the problem by exposing -setSuppressMakeKeyFront: to
the widget code, via an informal protocol in mozView.h.

Comment 12

[Mark Mentovai]

Comment on attachment 199250 [details] [diff] [review]
Patch

This isn't as icky as you led me to believe it would be.  Could you update the
comment in -viewsWindowDidBecomeKey to reflect the new implementation?

Comment 13

[Simon Fraser [no longer active]]

Fixed, trunk and branch.

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

*** Bug 312313 has been marked as a duplicate of this bug. ***