Closed
Bug 26101
Opened 25 years ago
Closed 24 years ago
Page position should be maintained after reflow
Categories
(Core :: XUL, defect, P3)
Core
XUL
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).
Comment 1•25 years ago
|
||
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
Comment 2•25 years ago
|
||
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
Comment 3•25 years ago
|
||
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
Comment 6•24 years ago
|
||
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
Comment 9•24 years ago
|
||
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).
Assignee | ||
Comment 10•24 years ago
|
||
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 ago → 24 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•