Closed Bug 26101 Opened 25 years ago Closed 24 years ago

Page position should be maintained after reflow

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

RESOLVED INVALID
Future

People

(Reporter: tj, Assigned: dcone)

Details

When clicking the button in the middle of the separator bar between a webpage large enough to scroll and the sidebar (the one that shrinks the sidebar to nothing), if you are on a scrollable page where there is room to scroll up, the page gets scrolled about 1/2 an inch. To see this: 1. go to M13 release notes in Mozilla browser 2. make sure your sidebar is open 3. under the "known issues" section, click on "java" 4. notice that the title "Java" is at the top of the window. 5. click the button to shink the sidebar to nothing 6. note that "Java" is now no longer visible 7. if you click the button again, to restore the sidebar, it scrolls back to normal ("Java" becomes visible again).
The page doesn't actually scroll: since hiding the sidebar produces more space, the text above the current position takes up less vertical space. Not specific to Sidebar, this happens whenever you resize the window. The question is: can the approximate position on the page be remembered and changed after a reflow caused by window size changes?
Assignee: slamm → beard
Component: Sidebar → Compositor
OS: Windows NT → All
QA Contact: paulmac → petersen
Hardware: PC → All
Summary: Shrinking sidebar causes scrollable webpage to scroll → Page position should be maintained after reflow
In my build from 6-Feb-2000, I don't see this behavior. This may be fixed already. It's really an XPFE issue, so changing owner for verification.
Assignee: beard → trudelle
Component: Compositor → XP Toolkit/Widgets
QA Contact: petersen → paulmac
Well, this has nothing to do with XPToolkit/XPFE, but I agree with zach, this is normal, although not expected, behavior. Even if we were able to find the same position to put at the top (doubtful, since the lines will break differently), there will still be a jarring reflow of text within the newly sized frame. tempted to resolve as invalid or worksforme (don agrees), but reassigning to rickg for conisideration as enhancement request.
Assignee: trudelle → rickg
Marking "remind" as feature request for later.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → REMIND
Sorry for the spam, changing QA contact.
QA Contact: paulmac → jrgm
reopening and marking Future...
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
Target Milestone: --- → Future
This needs to be moved up to someone who works at the app/window level. Clayton?
Assignee: rickg → clayton
Status: REOPENED → NEW
Dividing up claytons bugs to triage
Assignee: clayton → dcone
Don, I don't think this is a bug at all. Go to www.mozilla.org, scroll down until "hacking" is at the top of viewport on the left hand side, widen or narrow the window by 100px -- note that 'hacking' remains at the top of the viewport, but the content in the other columns has shifted up or down due to different line-breaking. (By the way IE5 shows identical behaviour for that test). I would recommend marking this as INVALID (not a bug).
I agree that this is invalid.. open up as another bug for a feature enhancment with a very detailed description of how the behavior should be if anyone disagrees.
Status: NEW → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.