157628 - [10.2, 10.3] After pressing Cancel/Preview/Print in print dialog, Plugin enabled page moves from background to top most window

Status: RESOLVED INVALID

(Camino Graveyard :: Printing, defect, P3)

Description

[Chris Petersen]

Build: 2002-07-14-05
Platform: OSX 10.1.5
Expected Results: Stacking order of windows should be preserved.
What I got: Plugin enable page (macromedia.com) moves to the top -most window
position.

Steps to reproduce: 

1) Launch Chimera
2) When default home opens, change its url to www.macromedia.com. Press return.
3) Open a new browser window
4) Choose Print from File menu.
5) In Print dialog, click either Cancel or Preview.
6) Notice the macromedia page (which was the background window) repositions
ahead of the window that was in front (top most window).

Comment 1

[Chris Petersen]

This happens with qt enabled pages too.

Comment 2

[Greg K.]

Confirmed using Chimera/20020715. Note that the title bar of the "background"
window still has the enabled appearance, and the "frontmost" window title bar is
disabled.

Comment 3

[Simon Fraser [no longer active]]

Weird carbon window funkiness, because windows with plugins have WindowRefs.
Does the print dialog code do any window activating itself?

Comment 4

[Chris Petersen]

Still seeing this issue with the 2003081002 Chimera NB under 10.2.6.

Comment 5

[Philip Machanick]

(In reply to comment #4)
> Still seeing this issue with the 2003081002 Chimera NB under 10.2.6.

Still seeing this with Camino 2004082512 (v0.8.1) on OS X 10.3.5. Print front
window, it skips back to behind previous nd-from-front window. I'm not sure it's
specific to any plug-in. I've see it with EVERY window I've tried this morning.

Comment 6

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

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

Comment 7

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

(In reply to comment #5)
> I'm not sure it's specific to any plug-in.
> I've see it with EVERY window I've tried this morning.

As I discovered in bug 181548 comment 3, having once visited a page with a
plugin will cause this for the rest of the browser session.  Quitting and
restarting returns Camino to normal behavior.

(Sorry for the extra noise for those cc'd on 181548)

Comment 8

[Martin Girschick]

Just as a sidenote: Issue still there with NB 2004122608 on Mac OS X 10.3.7.
Happens with Print Dialog and Paper Setup and as it seems doesn't matter if
Cancel or OK is pressed.

I guess it switches back to the first window openend (might be the one which had
the plugin originally). 

Comment 9

[Samuel Sidler (old account; do not CC)]

I can't reproduce this in the 2005050508 nightly. Someone else test this?

Comment 10

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

Still here for me, 20050513 0.8+ on 10.3.9.

Comment 11

[Simon Fraser [no longer active]]

Yup, still happens.

Comment 12

[Paul Borokhov (lensovet)]

whoa...major weirdness.
still occuring on 2005080808 (v0.9a2+) and 10.3.9

Comment 13

[Simon Fraser [no longer active]]

I'm no longer seeing this in a 0.9 branch build.

Comment 14

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

I just saw it in tonight's 2005082304 (v0.9a2+) branch with the steps in comment 0.

Comment 15

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

Is this 10.1/10.2/10.3-only, perhaps?  Samuel might have been on 10.4 already in
comment 9 and I think Simon is now....

Comment 16

[Simon Fraser [no longer active]]

That is possible, yes.

Comment 17

[Samuel Sidler (old account; do not CC)]

Is this a big deal? Window changing positions doesn't seem like major deal to me. Is this something we want fixed by 1.0 or can it be moved to 1.1? 10.3 users: what do you think?

Comment 18

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

The only times I've ever seen this were when trying to reproduce it or trying to reproduce bugs where plugins fubar the Camino print options pane or fubar pdf names.  But I don't print/pdf much.

Comment 19

[Paul Borokhov (lensovet)]

(In reply to comment #17)
> Is this a big deal? Window changing positions doesn't seem like major deal to
> me. Is this something we want fixed by 1.0 or can it be moved to 1.1? 10.3
> users: what do you think?
> 

LOL of course it's a big deal, you're trying to print something and after it finishes, your active window is no longer active! Imagine having 5 Word docs open and having it change the active doc every time you printed. That'd be fun.
This still happens, btw. Just checked with 2006061404 (v1.0+)

Comment 20

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

Having done a fair amount of printing recently, I can add that *any* printing operation causes it, for any tab in a window where one tab in said window has contained a plugin.  

IOW, the plugin doesn't have to be in the current tab (or even in any tab in the window anymore), just once-upon-a-time have been in a tab in the window that also contains the tab you're trying to print.

Comment 21

[Samuel Sidler (old account; do not CC)]

Since this doesn't affect newer OSes, targeting for Future. This bug will eventually become INVALID, I think.

Comment 22

[Stuart Morgan]

(In reply to comment #21)
> This bug will eventually become INVALID, I think.

I think that day has come; this would almost certainly be in core, and landing fixes for relatively minor, non-regression issues on the 1.8 branch is unrealistic at this point.