9659 - [feature] Resolve window targeting issues

Status: VERIFIED FIXED

(Core :: XUL, enhancement, P2)

Description

[Peter Trudelle]

Resolve window targeting issues	1 day	hyatt	0%	Resolve targeting
issues (problems with window naming).

Comment 1

[Peter Trudelle]

Mass changing all XPToolkit M10 feature 'bugs' to target as p2 enhancement for
M10

Comment 2

[David Hyatt]

Reassigning to danm.

Comment 3

[Peter Trudelle]

added original estimated duration to status whiteboard

Comment 4

[Peter Trudelle]

adding some possibly interested customers to cc list

Comment 5

[Dan M]

This is a catch-all schedule item reminding us that we'd like to be able to provide an improved
way to target windows, probably an API available from JavaScript.  Specifically, we're thinking
there should be a JS window property (a proxy for an actual global property) named something
like "active".  It should be useable in some way to target the most recently used window of a
particular type.  Perhaps it would be an associative array, so the topmost browser window's content
could be referenced with window.active["netscape:browser"].content (using the windowtype attribute
in navigator.xul).

This actually kind of sounds like fun, and I'm willing to take this on for M12 (I believe I'm out of time
for M11), if we hear that anyone wants this functionality for that thing we're calling "beta."  As it
stands, I believe this whole idea is just a helpful suggestion from the xptoolkit staff; I haven't heard
of anyone who is actually aching to use this.

Currently, all our "other window" targeting issues seem to be handled by the standard JS functionality
of window.opener, referencing an opened window by the value returned from window.open(), and
the nsIWindowMediator service.  That latter service already provides exactly the functionality described
above, it just has a less built-in, component service API.

The component service is clunkier to use, but more standard, in the sense that a new window property
built in to JS would be an issue of interest to the JS standards bodies, while the service object is not.
I'm pushing this enhancement out several milestones, and posting a request for comments on the xpfe
newsgroup. No potential clients that I know of have expressed interest in this functionality. We'll
implement this in the future, if potential clients speak up.

Comment 6

[Phil Peterson]

The issue I'm interested in (not sure if this is "window targeting" or not) is
dispatching URLs to the right windows. So http URLs in mail windows bring up a
browser, and mailto URLs in the browser bring up a message composition window.

Otherwise, having multiple mail windows open is a beta 2 feature, so we don't
really need to find the active mail/news window for beta 1.

Comment 7

[Dan M]

Hmm. Interesting point. We currently have a mechanism for locating the topmost
window by type, as long as there is one, as mentioned above.  And we have
a means to open a fresh window of a given type (open("chrome://whatever")).
We don't have a way to tie these two rather immiscible techniques together,
which seems to be what you're asking for.
  That's an interesting question.  I believe you need a combined method
like that for at least http:// URLs, and we don't have one yet that I know of.

Comment 8

[Phil Peterson]

I think some folks also want to tie this "URL dispatching" mechanism in with
MIME types. I think rpotts is working on that, so I'll cc him.

Comment 9

[Mike Shaver (:shaver emeritus)]

In 4.x, doesn't window.open called with an existing window's name give you a
handle to that window?  We'll need to implement that to compatibility, and it
sounds like it might solve your issues as well.

There's a security issue here, in that a content window script doing
``window.open("SomeChromeWindow")'' should get a handle to the sensitive chrome.

Comment 10

[Dan M]

In Mozilla, like in 4.x, window.open called with an existing window's name gives you a
handle to that window.  I think this doesn't solve Phil's problem, though.  To match 4.x
functionality, he needs to glom onto the topmost open browser window, whatever its name,
or make a new one.  Actually, he could try to open the topmost browser window and,
failing that, open a new one explicitly.  Maybe more convenience is unnecessary.  Maybe
we are already there.
  Security issues abound, of course.

Comment 11

[hangas]

Interesting feature.  I have not thought about this much, but it does occur to me
that on Windows we allow for a dialog to be modal to a window, so when we locate
the frontmost window of a particular type it may have a modal dialog hanging on
it.  If this is the case it may be strange to bring up content in that window.
Please make sure we can work properly with this.

Comment 12

[Paul MacQuiddy]

dividing up phillips qa contact bugs, he no longer works here

Comment 13

[Peter Trudelle]

Dan, didn't you say this was done?

Comment 14

[Dan M]

Arguably. We haven't implemented the nifty one-step "active" feature I mentioned 
above on 21 Sep 99. But all the required functionality is there; you just have to 
piece it together from the WindowMediator. Calling it fixed.

Comment 15

[Phil Peterson]

> The issue I'm interested in (not sure if this is "window targeting" or not) is
> dispatching URLs to the right windows.

This part is actually done by mscott's URL dispatching code now.

Comment 16

[Eli Goldberg]

Peter, would you like to:
 - verify this bug
 - let me know how it can be verified on a black box level (hah)
 - rubber-stamp it as verified without inspection?
 - anything else?

Thanks!

Comment 17

[Peter Trudelle]

I think this is resolved, verifying.