Open Bug 319646 Opened 20 years ago Updated 3 years ago

cached viewer bounds in fastback can be wrong

Categories

(Core :: DOM: Navigation, defect)

defect

Tracking

()

People

(Reporter: bryner, Unassigned)

Details

It's possible for the following scenario to happen: 1. new page starts to load. old page is cached in session history 2. before paint suppression fires, the content area is resized 3. the new content viewer resizes its previous viewer (see http://lxr.mozilla.org/seamonkey/source/layout/base/nsDocumentViewer.cpp#1790 ), but the cached viewer bounds on the SHEntry are not updated [later] 4. the content area is resized back to the original size If this occurs, then when the previous viewer is restored, we'll mistakingly think that it's already at the correct size, when in fact it's at the intermediate size. As a result, it will not be sized correctly for the current content area.
this would be nice to fix for ff 1.5.0.1 as it's impacting google safe browsing
Flags: blocking1.8.0.1?
without even a patch, let alone reviewed and trunk-tested, I don't see how this can make .0.1
Flags: blocking1.8.0.2?
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1-
(In reply to comment #2) ditto 1.8.0.2
Flags: blocking1.8.0.2? → blocking1.8.0.2-
Reassigning my bugs, since I'm not actually working on them.
Assignee: bryner → nobody
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.