71482 - page title setting should not rely on global history

Status: RESOLVED WORKSFORME

(Core Graveyard :: History: Global, defect, P2)

Description

[Judson Valeski]

Currently AddTitle() initiates, via RDF notification, page title setting. This
should be handled elswere as global history has nothing to do w/ page titles.

Comment 1

[Alec Flett]

it looks like we should be using nsIDocumentLoaderObsever, though that brings in
a ton of dependancies. I'm going to see what other options are available.

Comment 2

[Judson Valeski]

yea, that's the iface I was thinking of, but I didn't know what it would drag
in. Are the dependencies worth dragging it in to break the ugliness of haning
AddTitle() off of globahist?

So, currently nsGlobalHistory uses RDF as the notification mechanism. So, when
globalhist gets a titleSet(), it modifies RDF and someone higher up in the UI
chain listens to a titleChange() notification (or whatever it is in RDF land),
and updates the title appropriately. What if that UI RDF listener/observer were
triggered by layout doing it's notify that the <title> tag came in? The UI hunk
currently registering for RDF notification would need to register for layout
title notification. That would remove global hist from the loop completely.

Comment 3

[Alec Flett]

as much as I'd like to fix this in mozilla 0.9, I am overloaded and must push
this back a milestone. Sorry!

Comment 4

[Viswanath Ramachandran]

nav triage: moving to mozilla1.0 milestone in light of Alec's other deliverables
for mozilla0.9.1. 

Comment 5

[Paul Chen]

nav triage team:

Moving out to mozilla1.2

Comment 6

[Alec Flett]

in this, we should make sure we also rip out the code I added to nsDocShell.cpp
as a part of bug 102043

Comment 7

[Alec Flett]

Attachment: hook up the load listener to global history

I've checked in most the history load listener into:
http://lxr.mozilla.org/seamonkey/source/xpfe/components/history/src/nsHistoryLoadListener.cpp

http://lxr.mozilla.org/seamonkey/source/xpfe/components/history/src/nsHistoryLoadListener.h


I need to remove the printf()s and then this will be ready to check in.

Comment 8

[Alec Flett]

Attachment: make docshell no longer use nsIBrowserHistory

This patch removes the old dependency.

Comment 9

[Alec Flett]

you know what? I think I've completely changed my stance here.

I think I would now like a new interface, nsIGlobalHistory2, that embeddors can
implement, and we'll call methods on that to hide the page and set the title.
thoughts?

Comment 10

[Alec Flett]

Attachment: alternate approach: a new, frozen interface

This is what the alternate approach would look like

Another option is to call this nsIGlobalHistoryPresentation or something, and
make it a totally seperate interface, not even deriving from nsIGlobalHistory.

Comment 11

[Alec Flett]

does anyone have any opinions on the two approaches? I'm leaning towards the
latter solution (nsIGlobalHistory2) because it provides a far easier method of
getting page titles and hiding 302-redirects.

Comment 12

[Alec Flett]

no decision here, moving to 0.9.8

Comment 13

[Alec Flett]

*sigh* 0.9.8 was way to short. moving all my bugs to 0.9.9

Comment 14

[Winnie Lam]

minusing to topembed- and adding embed as per edt triage.  not related to a
particular embedding customer.

Comment 15

[Alec Flett]

not critical to 1.0, moving out for now.

Comment 16

[Alec Flett]

moving bugs to mozilla 1.2alpha that missed 1.1beta

Comment 17

[Alec Flett]

moving some stuff out to mozilla1.2beta that didn't make the mozilla1.2alpha train

Comment 18

[Alec Flett]

mozilla 1.1alpha is more or less done, so I'm moving non-critical mozilla1.2beta
bugs out to the next milestone to make room for the mozilla1.1alpha bugs that
didn't make it.

Comment 19

[Jaime Rodriguez, Jr.]

Corfirming topembed- [T2] per EDT triage.

alecf: should the "fix in hand" comment in the whiteboard be removed?

Comment 20

[Alec Flett]

Furturing bugs that keep getting knocked from milestone to milestone...if you
feel this is in error, please nominate this bug using the appropriate keyword.

Comment 21

[:Gavin Sharp [email: [e-mail]]]

This was filed against the old history implementation, and is no longer relevant to the new one AFAICT.