Closed Bug 296745 Opened 19 years ago Closed 19 years ago

history lists URL of previous page instead of current one with bfcache enabled

Categories

(Core :: DOM: Navigation, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: benoit, Assigned: bryner)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b2) Gecko/20050530
Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b2) Gecko/20050530

In History, the titles of pages you visited is that of the page you were on
before accessing it when exiting them with the Back button.

Say you are on Google. Now click on a bookmark that leads you to mozilla.org.
Press Back. Now go into your History, and look up your entry of
http://www.mozilla.org/. It will read "Google" instead of the site's title.

This happens only with bfcache enabled.

Reproducible: Always

Steps to Reproduce:
1. Load a page. Any page.
2. Click on a link on that page, or click a bookmark.
3. Press Back.
4. Look up the page you just visited in History.

Actual Results:  
The title listed is that of the previous page.

Expected Results:  
Listed the last visited page's title.
OS: other → Windows 95
Confirming in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050529
build.
Can easily reproduce it, following reporter's steps on build 20050607/WinXP. The
history entry'stitle is corrected only when you click on it (and the page is
loaded again). This breaks an essential History feature. Additionally it might
be the cause of bug 293235. ->NEW, Severity->Normal, OS->All.
Perhaps a fallout of an already reported bfcache bug that it's too technical for
us non-hackers to understand. If that is the case, better don't duplicate this
one because the summary makes it easy to verify whether it has been fixed or not.
Severity: trivial → normal
Status: UNCONFIRMED → NEW
Component: History: Global → History: Session
Ever confirmed: true
OS: Windows 95 → All
forget my speculation about bug 293235. Doesn't seem related, the uri is
correctly stored.
Don't restore the title until mOSHE and mCurrentURI are updated to the new
page.
Assignee: nobody → bryner
Status: NEW → ASSIGNED
Attachment #186714 - Flags: superreview?(bzbarsky)
Attachment #186714 - Flags: review?(bzbarsky)
Comment on attachment 186714 [details] [diff] [review]
move the title-restore later

darin, feel free to r/sr as well if boris can't get to this
Attachment #186714 - Flags: superreview?(bzbarsky) → superreview?(darin)
Comment on attachment 186714 [details] [diff] [review]
move the title-restore later

switching reviewers, boris is away for awhile
Attachment #186714 - Flags: review?(bzbarsky) → review?(cbiesinger)
Comment on attachment 186714 [details] [diff] [review]
move the title-restore later

Very obvious fix.  r+sr=darin
Attachment #186714 - Flags: superreview?(darin)
Attachment #186714 - Flags: superreview+
Attachment #186714 - Flags: review?(cbiesinger)
Attachment #186714 - Flags: review+
Comment on attachment 186714 [details] [diff] [review]
move the title-restore later

Requesting approval for fastback fix. Does not impact non-fastback.
Attachment #186714 - Flags: approval1.8b3?
Attachment #186714 - Flags: approval1.8b3? → approval1.8b3+
checked in
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
verified fixed with FF 20050621 on WinXP.
Status: RESOLVED → VERIFIED
Component: History: Session → Document Navigation
QA Contact: history.global → docshell
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: