Closed Bug 73131 Opened 24 years ago Closed 24 years ago

Change nsGtkMozRemoteHelper window posing

Categories

(Core Graveyard :: Embedding: GTK Widget, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: trudelle, Assigned: blizzard)

References

()

Details

(Keywords: embed)

Need to change how nsGtkMozRemoteHelper windows are invoked so they can be 
overridden by embedding clients. Assigning to blizzard, who apparently wrote 
this code. Some details below, more at URL above; danm will be happy to help and 
answer questions.

UI Posed by Gecko (Up Calls)
============================
These are calls to window.open, in one form or another, which are relevant to 
embedding. They're split into calls and callers, where a call is considered to 
be a base-level call to window.open which should be API-ized like we're 
discussing, and a caller is something which currently uses window.open but 
should use one of these new APIs when they're created.

I've tried to categorize these sensibly... Each category implies a UI-posing 
component with methods for each item marked "CALL" in that category. Items 
marked "CALLER" in a given category may imply a new method in that component 
(eg. the print dialog stuff), or may just be a caller of some other extant 
method in a different component (eg. the uri loader opening a new window).

Widget-Fu
CALLER: /widget/src/gtk/nsGtkMozRemoteHelper.cpp#934
  in ::OpenXULWindow, widget property change notification opens XUL windows, 
namely "open location" dialog. blizzard: wtf?
Adding mozilla0.9 keyword, dependency
Blocks: 71837
Keywords: mozilla0.9
I wrote that code a long time ago.  It should all be using the uri loader
service where possible and targetting uri loads at the right windows.  There are
some other things in that service that should be doing things like adding
bookmarks and saving files and other crazy things.  It's quite the dumping
ground.  It needs work.
No longer blocks: 71837
Blocks: 65233
Apologies for all the bug spam. For the detailed overview of this task, see
danm's document:

  http://www.mozilla.org/xpfe/embedding-dialogs.html

See my first cut at a component-wise categorization:

  http://bugzilla.mozilla.org/showattachment.cgi?attach_id=27972

And if you want to laugh, see also my brainless incomplete IDL for these components:

  http://bugzilla.mozilla.org/showattachment.cgi?attach_id=28175

dr
Keywords: embed
Blizzard sez: This code happens *only* when you do "mozilla -remote" from the
command line, which opens a url in an existing window if there is one, or opens
a new window otherwise. In other words, the remote-helper is the only consumer
of this open window. First of all, this code never occurs in the embedded world,
and second of all, it needs a major overhaul which would include eliminating
these calls anyway.

So this is a WONTFIX - it turns out to be a case we don't care about in 65233,
and I'll take it out of the next component breakdown list.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
verified, invalids, and dups, oh my
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets → X-remote
Component: X-remote → Embedding: GTK Widget
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.