Status

defect
P1
major
RESOLVED FIXED
14 years ago
14 years ago

People

(Reporter: grikdog, Assigned: sfraser_bugs)

Tracking

({fixed1.8})

unspecified
Camino1.0
PowerPC
macOS
Bug Flags:
camino1.0 +

Details

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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

14 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

14 years ago
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

14 years ago
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

14 years ago
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
could this be fallout from the focus/activation changes for the blank window?
(Assignee)

Comment 6

14 years ago
Quite possibly, yes. A solid testcase would be good.
Target Milestone: --- → Camino1.0

Comment 7

14 years ago
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

14 years ago
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.
(Assignee)

Comment 9

14 years ago
Yeah, I think this was me.
Assignee: mikepinkerton → sfraser_bugs
(Assignee)

Comment 10

14 years ago
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:).


Depends on: 297343
Flags: camino1.0+
Priority: -- → P1
(Assignee)

Comment 11

14 years ago
Posted patch PatchSplinter Review
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.
Attachment #199250 - Flags: review?(mark)

Comment 12

14 years ago
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?
Attachment #199250 - Flags: review?(mark) → review+
(Assignee)

Comment 13

14 years ago
Fixed, trunk and branch.
Keywords: fixed1.8
(Assignee)

Updated

14 years ago
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
*** Bug 312313 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.