Closed
Bug 450576
Opened 16 years ago
Closed 11 years ago
[Mac] getZOrderDOMWindowEnumerator is broken on Mac
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: ecfbugzilla, Unassigned)
References
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
roc
:
superreview+
|
Details | Diff | Splinter Review |
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.
Comment 1•16 years ago
|
||
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).
Reporter | ||
Comment 2•16 years ago
|
||
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
Updated•16 years ago
|
Summary: getZOrderDOMWindowEnumerator is broken on Mac → [Mac] getZOrderDOMWindowEnumerator is broken on Mac
Comment 3•16 years ago
|
||
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
Comment 4•16 years ago
|
||
and a few other places. (this used to be reliable, I am very sure it'd be 1.9-only)
Comment 5•16 years ago
|
||
Bug 462222 was filed to correct the defines as suggested in comment 3 in case this doesn't get fixed on time.
Blocks: 462222
Updated•16 years ago
|
Flags: blocking1.9.1? → blocking1.9.1+
Comment 8•16 years ago
|
||
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.
Comment 10•16 years ago
|
||
Before we do any real work in this code lets clean it up. No functional changes in this patch.
Attachment #355173 -
Flags: superreview?(roc)
Comment 11•16 years ago
|
||
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.
Comment 13•16 years ago
|
||
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.)
Comment 15•16 years ago
|
||
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+
Comment 16•16 years ago
|
||
Pushed: window mediator/enumerator cleanup v1.1 http://hg.mozilla.org/mozilla-central/rev/000821b9b9ef
Comment 17•16 years ago
|
||
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-
Comment 18•16 years ago
|
||
Josh, can you give more details about your investigation? This should block 1.9.2.
Flags: blocking1.9.2?
Comment 19•16 years ago
|
||
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.
Updated•15 years ago
|
Flags: blocking1.9.2? → blocking1.9.2-
Comment 21•15 years ago
|
||
Any suggestions on how to proceed with the redesign?
Updated•15 years ago
|
Assignee: joshmoz → joelr
Comment 22•13 years ago
|
||
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.
Comment 23•13 years ago
|
||
I can't recall the state of things here.
Comment 24•13 years ago
|
||
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).
Reporter | ||
Comment 25•13 years ago
|
||
(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.
Updated•11 years ago
|
Assignee: joelr → nobody
Comment 26•11 years ago
|
||
Comment 22 and bug 874566 comment 16 suggest this is WFM.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Comment 27•9 years ago
|
||
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.
Description
•