Change Find dialog for embedding override

VERIFIED FIXED in mozilla0.9

Status

SeaMonkey
General
--
enhancement
VERIFIED FIXED
17 years ago
13 years ago

People

(Reporter: Peter Trudelle, Assigned: Conrad Carlen (not reading bugmail))

Tracking

({embed})

Trunk
mozilla0.9
embed

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 years ago
Need to change how Find dialog is invoked so it can be overridden by embedding 
clients.  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).

Find Component
--------------
(This probably just needs to be revamped in-place to fit with the UI component 
overriding architecture we're going to have)

CALL: /xpfe/components/find/src/nsFindComponent.cpp#485
  chrome://global/content/finddialog.xul
  chrome://global/content/replacedialog.xul
(Reporter)

Comment 1

17 years ago
Adding mozilla0.9 keyword, dependency
Blocks: 71837
Keywords: mozilla0.9
(Assignee)

Comment 2

17 years ago
Don't think this is an issue because the find component in xpfe is not needed
for text searching in embedding. There is an interface
http://lxr.mozilla.org/seamonkey/source/embedding/browser/webBrowser/nsIWebBrowserFind.idl
which can be gotten from an nsIWebBrowser which handles finding without
overriding any UI. It's all down calls - no up calls. This is prefereable
because, for embedding, the whole find component can be skipped. Both mfcEmbed
and PPEmbed happily use this API.

Updated

17 years ago
No longer blocks: 71837

Updated

17 years ago
Blocks: 65233

Comment 3

17 years ago
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

Updated

17 years ago

Comment 4

17 years ago
This bug is just us trying to be certain we didn't miss anything. It stems 
entirely from this line-o'-source:

(xpfe/components/find/src/nsFindComponent.cpp, rev 1.56 line 485)
rv = parent->OpenDialog( jsContext, argv, 4, &newWindow );

Based on Conrad's comment above that the xpfe "find" component is intended to not 
ship with the embedded package, this worrisome line will never find its way into 
an embedded app. Closing.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla0.9

Comment 5

17 years ago
rockin'.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.