Closed Bug 292933 Opened 19 years ago Closed 19 years ago

Info. popup box on tinderbox display wrong details

Categories

(Core :: DOM: Navigation, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.8beta3

People

(Reporter: jaime.bugzilla, Assigned: bryner)

References

()

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050504 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050504 Firefox/1.0+

Information in the popup box is always displayed for previously selected item

Reproducible: Always

Steps to Reproduce:
1. Set browser.sessionhistory.max_viewers to 50
2. Go to Tinderbox page
3. Select a name under guilty
4. Select Last checkin
5. Go back
6. Select a different name

Actual Results:  
Details for the previously selected name are displayed

Expected Results:  
Details for the new person selected are displayed

Setting browser.sessionhistory.max_viewers to 0 gives expected behaviour.
No longer depends on: blazinglyfastback
Status: UNCONFIRMED → NEW
Depends on: blazinglyfastback
Ever confirmed: true
No longer depends on: blazinglyfastback
Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b2) Gecko/20050505 Firefox/1.0+ Beast

WFM - browser.sessionhistory.max_viewers set to 10
I have viewers set to 5, and I see the problem as reported.  Also I note that
the 'link' is not being marked as 'read', takes a page refresh to update the
link to the status of 'read'. 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050504
Firefox/1.0+

I can confirm this with the 20050504 Windows trunk build and saw the problem
while using bfcache builds prior to bfcache landing on the trunk.  My
browser.sessionhistory.max_viewers config setting is 5.
It looks like what's happening here is that the frame for the details window
gets put in the session history cache. Since we only look up subframes' in the
cache by the frame number, when we attempt to find the new details page in the
cache, the frame number is the same and we get the old cache entry. Since we
never check the returned history entry's URI against the requested URI, we
happily use its content viewer, leading to the wrong page being loaded.

I'm not sure why this works with bfcache off, do we cache more aggressively with
it on, perhaps?
I'm not sure exactly why mLSHE ends up being non-null here, but in any case, it
should be nulled out when restoring a presentation.  This makes sure that
GetChildSHEntry returns null, which it's supposed to when clicking on a
tinderbox popup link.
Assignee: nobody → bryner
Status: NEW → ASSIGNED
Attachment #185201 - Flags: superreview?(bzbarsky)
Attachment #185201 - Flags: review?(bzbarsky)
Comment on attachment 185201 [details] [diff] [review]
don't leave mLSHE hanging around

darin offered to take a look at this.
Attachment #185201 - Flags: superreview?(darin)
Attachment #185201 - Flags: superreview?(bzbarsky)
Attachment #185201 - Flags: review?(darin)
Attachment #185201 - Flags: review?(bzbarsky)
Comment on attachment 185201 [details] [diff] [review]
don't leave mLSHE hanging around

Please add a detailed comment explaining why this is being done.

r+sr=darin
Attachment #185201 - Flags: superreview?(darin)
Attachment #185201 - Flags: superreview+
Attachment #185201 - Flags: review?(darin)
Attachment #185201 - Flags: review+
Comment on attachment 185201 [details] [diff] [review]
don't leave mLSHE hanging around

requesting approval for this fastback-only fix
Attachment #185201 - Flags: approval1.8b3?
Flags: blocking1.8b3+
Comment on attachment 185201 [details] [diff] [review]
don't leave mLSHE hanging around

a=me with comment (too bad we can't fix the cybercrud names -- L is for
Loading, we gather) for 1.8b3.

/be
Attachment #185201 - Flags: approval1.8b3? → approval1.8b3+
checked in
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
r=bzbarsky, fwiw (just got out of plane-stuff, finally).
Target Milestone: --- → mozilla1.8beta3
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.

Attachment

General

Created:
Updated:
Size: