Closed Bug 296745 Opened 20 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: