Open
Bug 319646
Opened 20 years ago
Updated 3 years ago
cached viewer bounds in fastback can be wrong
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
NEW
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.
Reporter | ||
Comment 1•20 years ago
|
||
this would be nice to fix for ff 1.5.0.1 as it's impacting google safe browsing
Flags: blocking1.8.0.1?
Comment 2•20 years ago
|
||
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-
Comment 3•19 years ago
|
||
(In reply to comment #2)
ditto 1.8.0.2
Flags: blocking1.8.0.2? → blocking1.8.0.2-
Reporter | ||
Comment 4•17 years ago
|
||
Reassigning my bugs, since I'm not actually working on them.
Assignee: bryner → nobody
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•