Closed Bug 450576 Opened 16 years ago Closed 11 years ago

[Mac] getZOrderDOMWindowEnumerator is broken on Mac

Categories

(Core :: Widget: Cocoa, defect)

All
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jwkbugzilla, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

There is already bug 156333 and bug 370134 for the same issue on Linux and OS/2, but nsIWindowMediator.getZOrderDOMWindowEnumerator isn't returning anything useful on Mac either. From the source code it seems that the list is only updated properly on Windows, for all other operating systems the result is random. This is particularly annoying for Mac dialogs because you want to open them with the current top-most dialog as their parent (otherwise they won't appear until that dialog is closed). Right now, there is no way to get that top-most dialog reliably.

At the very least this should be commented in the IDL. Solving the issue and making sure the list gets updated on OS X would be nicer of course.
Is this true for both FF2 and FF3?

If so, it's probably better to categorize this as "Widget: Cocoa" (since Widget: Mac, like FF2, is becoming obsolete).
I don't know whether this affects Firefox 2, only hit the issue with XULRunner 1.9. Moving to "Widget: Cocoa".
Component: Widget: Mac → Widget: Cocoa
QA Contact: mac → cocoa
Summary: getZOrderDOMWindowEnumerator is broken on Mac → [Mac] getZOrderDOMWindowEnumerator is broken on Mac
Sonofa.  Josh, can you look at fixing this for 3.1?  This is why opening links from external apps is flaky in Fx3 (this used to work).

Otherwise we need to change the defines here:

http://mxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserContentHandler.js#253
and a few other places.

(this used to be reliable, I am very sure it'd be 1.9-only)
Bug 462222 was filed to correct the defines as suggested in comment 3 in case this doesn't get fixed on time.
Blocks: 462222
This feels like significant platform bustage.
Flags: blocking1.9.1?
Did this work in Gecko 1.8.x?
Flags: blocking1.9.1? → blocking1.9.1+
Yes, it did.
We don't have a way to reliably get z-order update events in Cocoa, but we can get a list of windows in z-order at any given time. We'll probably have to change the window mediator to get a z-ordered list of windows from widget code instead of caching such a list and keeping it updated. That'll probably work on all platforms.
Before we do any real work in this code lets clean it up. No functional changes in this patch.
Attachment #355173 - Flags: superreview?(roc)
We should reconsider blocking because of how complicated a fix would be. The window mediator code is very Windows-centric and I doubt it worked well in Gecko 1.8 on Mac OS X.
Flags: blocking1.9.1+ → blocking1.9.1?
Look OK but why insert blank lines to make two blank lines between functions? We don't use that style anywhere.
It was 3 blank lines between many functions, I just picked 2 habitually since that is what we use in Cocoa widgets. I can change it to 1.
Please. We use 1 almost everywhere. (I don't see why Cocoa widgets should be different either.)
Same thing with only 1 newline between functions.
Attachment #355173 - Attachment is obsolete: true
Attachment #355195 - Flags: superreview?(roc)
Attachment #355173 - Flags: superreview?(roc)
Attachment #355195 - Flags: superreview?(roc) → superreview+
Pushed: window mediator/enumerator cleanup v1.1

http://hg.mozilla.org/mozilla-central/rev/000821b9b9ef
After further investigation, it is true that this will be a very risky fix. I don't think we can block 1.9.1 for this. And again, I highly doubt this really worked well in Gecko 1.8 on Mac OS X.
Flags: blocking1.9.1? → blocking1.9.1-
Josh, can you give more details about your investigation?

This should block 1.9.2.
Flags: blocking1.9.2?
The current z-order system is complex, fragile, and appears to be very Windows-centric (designed around how Win32 works). We don't get z-order update events on Mac OS X like Win32 does so we have to redesign how z-order enumerators and events work.
Hardware: PowerPC → All
Flags: blocking1.9.2? → blocking1.9.2-
Any suggestions on how to proceed with the redesign?
Assignee: joshmoz → joelr
Is this still a bug? Bug 455694 will need this to work properly, but I can't reproduce any problems.

From some testing (on trunk) with calling Services.wm.getZOrderDOMWindowEnumerator() directly, it seems to always enumerate browser windows in the correct Z-order. I can open/close/rearrange windows, and no matter what I do the result is correct. (I even tried moving things to different Spaces, and it still seems fine.)

Is there some trick to get things into an incorrect/broken state? Comment 1 implies the result was totally useless. So I wonder if I'm missing something obvious, or if it's actually working now.

Josh's comment 19 says "z-order update events on Mac OS X like Win32 does", so I'm not sure how this started working if it needed major rework. Though bug 178324 (focus rewrite) changed a bunch of things. My only guess is that we might miss externally-triggered Z changes, but I've no idea if/how that can happen.
I can't recall the state of things here.
Maybe comment #19 was thinking of nsIXULWindow and the various ways of toggling a window's z-index (normalZ, raisedZ etc) which think works on windows. On mac, it "kind of" worked, but that disappeared when we switched to cocoa (see bug 404283).
(In reply to comment #22)
> Is this still a bug? Bug 455694 will need this to work properly, but I can't
> reproduce any problems.

My original setup was an application (TomTom HOME) using modal dialogs, sometimes with one modal dialog opening another. Given that the application is no longer supported (and switched to a different approach long ago) I don't know whether the issue still exists.
Assignee: joelr → nobody
Comment 22 and bug 874566 comment 16 suggest this is WFM.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
See Also: → 1214585
I've hit this bug again in a different context. I'm not sure whether this is a regression or whether this bug was never completely fixed, so I filed a new bug on it (bug 1214585).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: