318931 - History/Bookmarks page title changes, but tab title and location do not

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: History, defect)

Description

[Chris Lawson (gone)]

1) Load the Bookmarks Manager or History.
2) Note window title, tab title, and location bar all correspond to appropriate view.
3) Click on whichever one you didn't select in the sidebar.
4) Note that window title changes, but tab title and location bar do not. They probably should.

Comment 1

[Samuel Sidler (old account; do not CC)]

This is annoying, I'll admit... but until there's code, it's 1.1 material.

Comment 2

[Chris Lawson (gone)]

This must be a recent regression. I don't see it in the 27 November trhunk nightly, and the previous bug we had on this (bug 285097) was fixed in July.

cl

Comment 3

[Chris Lawson (gone)]

Simon, is it possible your Page Info checkins (you had a whole mess of checkins around 01 Dec 2005) broke this? If so, how? I've been trying to decipher the diffs for the last hour and a half and I've made no progress.

cl

Comment 4

[Simon Fraser [no longer active]]

The issue is that when you click on the History item, we don't actually load about:history in that case (which is when the tab/window title normally gets set). So we'll either have to start doing that (which might be slow), or manually change the tab/window title (which should be pretty easy).

Comment 5

[Chris Lawson (gone)]

Patch coming for this and for bug 335979.

cl

Comment 6

[Chris Lawson (gone)]

Hrm. OK.

I have the window/tab title thing fixed, but location is proving rather problematic. I can fake it by setting the stringValue of mURLBar to "about:history" or "about:bookmarks" as needed, but that doesn't mean the BrowserWrapper actually thinks it's at that URL.

I'm not sure there's any "good" solution short of actually loading about:history every time we click the history collection.

Comments?

cl

Comment 7

[froodian (Ian Leue)]

This is starting to look like it's causing some weird behavior, and blocking some history validation related bugs.  Simon, Pink, could you weigh in on the best thing here?

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Simon/Mike, can we get an answer to comment 6?  This is blocking some of our validation bugs for 1.1 (and a regression).

Comment 9

[Simon Fraser [no longer active]]

Mucking with the string value of mURLBar is a bad thing.

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Minusing for 1.0.4 because we've determined there's no way this is getting fixed before Camino 1.2. :(

Comment 11

[Chris Lawson (gone)]

I think what we're going to have to do here is just bite the bullet and reload the History collection every time, since no one has suggested any reasonable alternative solutions in the last year and a half.

ISTR I may have tried this at one point in the past and the slowdown in a debug build with several megs of history (a year's worth or so) wasn't even really noticeable, or was only mildly noticeable. If there *is* a significant slowdown, we should discuss whether the tradeoff is worth it.

cl

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Mass un-setting milestone per 1.6 roadmap.

Filter on RemoveRedonkulousBuglist to remove bugspam.

Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.

Comment 13

[Takanori MATSUURA]

This bug lies at rest in the graveyard.