The default bug view has changed. See this FAQ.

Fastback(bfcache) breaks visited links marking if frame page

RESOLVED FIXED

Status

()

Core
Document Navigation
RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: masayuki, Assigned: Brian Ryner (not reading))

Tracking

({fixed1.8, qawanted})

Trunk
x86
All
fixed1.8, qawanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
1. See frame page.
(e.g., http://www.cgl.ucsf.edu/chimera/docs/ProgrammersGuide/Examples/ )
2. Select "Show Only This Frame" in any frame.
3. Back to frame page by back button.
4. Click left frame's link.

The clicked link isn't marked to visited. This problem is only occured with
Fastback(bfcache).

Comment 1

12 years ago
I can reproduce on Trunk/Linux.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050906 Firefox/1.6a1
(Reporter)

Updated

12 years ago
OS: Windows XP → All
(Assignee)

Updated

12 years ago
Assignee: nobody → roc
Brian, this is happening because subframe documents don't get OnPageShow
notifications. Is that the expected behaviour? Can you suggest how I can detect
that the subframe document is alive again?

Comment 3

12 years ago
Is this depend on bug 274784?
Blocks: 274784
(Assignee)

Comment 4

12 years ago
(In reply to comment #2)
> Brian, this is happening because subframe documents don't get OnPageShow
> notifications. Is that the expected behaviour? Can you suggest how I can detect
> that the subframe document is alive again?

This is not the expected behavior -- pageshow events should be firing.  It's possible that this is caused by bug 312117, if it's trunk-only.
(Assignee)

Comment 5

12 years ago
It's not that, this happens on the branch as well.
(Assignee)

Comment 6

12 years ago
Created attachment 201490 [details] [diff] [review]
patch

We have to clear mEODForCurrentDocument as we start the fake loads for subframes, or they won't notify the content viewer in EndPageLoad, which in turn won't call nsDocument::OnPageShow.
Assignee: roc → bryner
Status: NEW → ASSIGNED
Attachment #201490 - Flags: superreview?(bzbarsky)
Attachment #201490 - Flags: review?(bzbarsky)
Comment on attachment 201490 [details] [diff] [review]
patch

Seems reasonable.  Probably worth getting in on branch too...
Attachment #201490 - Flags: superreview?(bzbarsky)
Attachment #201490 - Flags: superreview+
Attachment #201490 - Flags: review?(bzbarsky)
Attachment #201490 - Flags: review+
(Assignee)

Comment 8

12 years ago
checked in on trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Comment 9

12 years ago
Comment on attachment 201490 [details] [diff] [review]
patch

Requesting rc2 approval.  I think this fix is really safe, and it addresses a noticeable issue for users who use link coloring to figure out where they've been.
Attachment #201490 - Flags: approval1.8rc2?
It's not just that, right? Is it not also an API issue for Web developers who expect to receive these events?
(Assignee)

Comment 11

12 years ago
That too.

Comment 12

12 years ago
Can we get QA verification on the trunk for this.
Keywords: qawanted

Comment 13

12 years ago
I'll do the verify today.  

Comment 14

12 years ago
Comment on attachment 201490 [details] [diff] [review]
patch

Approved r.e. discussion in bug triage today.
Attachment #201490 - Flags: approval1.8rc2? → approval1.8rc2+
(Assignee)

Comment 15

12 years ago
Checked in on the branch.
Keywords: fixed1.8

Updated

9 years ago
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
You need to log in before you can comment on or make changes to this bug.