page title setting should not rely on global history

RESOLVED WORKSFORME

Status

()

Core
History: Global
P2
normal
RESOLVED WORKSFORME
17 years ago
9 years ago

People

(Reporter: Judson Valeski, Assigned: Alec Flett)

Tracking

({embed, topembed-})

Trunk
Future
x86
Linux
embed, topembed-
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fix in hand [T2])

Attachments

(3 attachments)

(Reporter)

Description

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

Comment 1

17 years ago
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.
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9
(Assignee)

Updated

17 years ago
Blocks: 71511
(Reporter)

Comment 2

17 years ago
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.
(Assignee)

Comment 3

17 years ago
as much as I'd like to fix this in mozilla 0.9, I am overloaded and must push
this back a milestone. Sorry!
Target Milestone: mozilla0.9 → mozilla0.9.1
(Reporter)

Updated

17 years ago
No longer blocks: 71511
nav triage: moving to mozilla1.0 milestone in light of Alec's other deliverables
for mozilla0.9.1. 
Target Milestone: mozilla0.9.1 → mozilla1.0
(Assignee)

Updated

17 years ago
Blocks: 58613

Comment 5

17 years ago
nav triage team:

Moving out to mozilla1.2
Target Milestone: mozilla1.0 → mozilla1.2
(Assignee)

Comment 6

17 years ago
in this, we should make sure we also rip out the code I added to nsDocShell.cpp
as a part of bug 102043
Target Milestone: mozilla1.2 → mozilla0.9.7
(Assignee)

Comment 7

17 years ago
Created attachment 58047 [details] [diff] [review]
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.
(Assignee)

Updated

17 years ago
Whiteboard: fix in hand
(Assignee)

Comment 8

17 years ago
Created attachment 60694 [details] [diff] [review]
make docshell no longer use nsIBrowserHistory

This patch removes the old dependency.
(Reporter)

Updated

17 years ago
Attachment #60694 - Flags: review+
(Assignee)

Comment 9

17 years ago
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?
(Assignee)

Comment 10

17 years ago
Created attachment 60703 [details] [diff] [review]
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.
(Assignee)

Comment 11

17 years ago
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.
(Assignee)

Comment 12

17 years ago
no decision here, moving to 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
(Assignee)

Comment 13

17 years ago
*sigh* 0.9.8 was way to short. moving all my bugs to 0.9.9
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.8 → mozilla0.9.9
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.9 → mozilla1.0
(Reporter)

Updated

16 years ago
Keywords: topembed

Comment 14

16 years ago
minusing to topembed- and adding embed as per edt triage.  not related to a
particular embedding customer.
Keywords: topembed → embed, topembed-
(Assignee)

Comment 15

16 years ago
not critical to 1.0, moving out for now.
Target Milestone: mozilla1.0 → mozilla1.1beta
(Assignee)

Comment 16

16 years ago
moving bugs to mozilla 1.2alpha that missed 1.1beta
Target Milestone: mozilla1.1beta → mozilla1.2alpha
(Assignee)

Comment 17

16 years ago
moving some stuff out to mozilla1.2beta that didn't make the mozilla1.2alpha train
Target Milestone: mozilla1.2alpha → mozilla1.2beta
(Assignee)

Comment 18

16 years ago
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.
Target Milestone: mozilla1.2beta → mozilla1.3alpha

Comment 19

16 years ago
Corfirming topembed- [T2] per EDT triage.

alecf: should the "fix in hand" comment in the whiteboard be removed?
Whiteboard: fix in hand → fix in hand [T2]
(Assignee)

Comment 20

16 years ago
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.
Target Milestone: mozilla1.3alpha → Future
This was filed against the old history implementation, and is no longer relevant to the new one AFAICT.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.