59285 - nsIWebBrowserChrome acts like a progress listener.

Status: VERIFIED WONTFIX

(Core Graveyard :: Embedding: APIs, defect, P3)

Description

[Judson Valeski]

nsIWebBrowserChrome::SetStatus() is for receiving load progress data (strings).
Shouldn't we push this into nsIWebProgressListener? implementing
nsIWebBrowserChrome implicitly registers the window as a "progress listener" in
this context. We're scattering progress listeners around :-/.

Comment 1

[Paul Wyskoczka]

Updating QA Contact

Comment 2

[Michael Dunn]

Correction: Changing QA contact for the Embed API bugs to David Epstein.

Comment 3

[Radha on family leave (not reading bugmail)]

retargeting for mozilla 1.0

Comment 4

[[e-mail] (gone - use [e-mail] instead)]

Silly question on my part here, but is this what causes the progress meter to be
set to the busy state when you select the up arrow on the scrollbar?

Comment 5

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 6

[David Epstein]

Changed qa contact to Dharma. nsIWebBrowserChrome is his area.

Comment 7

[Asa Dotzler [:asa]]

don't move bugs that are in the 1.0 dependency tree. sorry.

Comment 8

[rpotts (gone)]

hmmm...  well, since we've frozen nsIWebBrowserChrome, i think this bug is
pretty much moot now :-)

i think we can live with nsIWebBrowserChrome::SetStatus(...) as the notification
for 'status bar' text.  and nsIWebProgressListener::OnStatus(...) as a 'lower
level' notification that provides more contextual information...
jud, if you agree, i'll close this one out as WONTFIX ;-)

-- rick

Comment 9

[Judson Valeski]

yup. WONTFIX'ing.

Comment 10

[David Epstein]

verified.