Closed
Bug 18649
Opened 25 years ago
Closed 25 years ago
ScrollFrameIntoView and SCROLL_IF_NOT_VISIBLE
Categories
(Core :: Layout, enhancement, P3)
Core
Layout
Tracking
()
VERIFIED
FIXED
M14
People
(Reporter: hjtoi-bugzilla, Assigned: rods)
References
Details
(Whiteboard: Fix in my tree)
Attachments
(3 files)
3.80 KB,
patch
|
Details | Diff | Splinter Review | |
412 bytes,
text/html
|
Details | |
141 bytes,
text/html
|
Details |
It would be nice if nsIPresShell::ScrollFrameIntoView would recognize a new type of scrolling, call it: NS_PRESSHELL_SCROLL_ONLY_IF_NOT_FULLY_VISIBLE Currently the default behaviour after following a link is that we scroll horizontally to the location of the target. This is annoying to say the least. For example, if you have: A term is this This is a definition, here is <target>the target</target> of some link. and you have a link pointing to the target and you have a horizontal scroll bar it will show up like this: <target>the target</target> of some and you need to scroll left to see what is being said. What it should do for horizontal scroll is that if and only if the frame is not *completely* visible would it scroll horizontally. Note that you can not use NS_PRESSHELL_SCROLL_LEFT because some languages are read from right to left and in that case scroll left would be the last thing they wanted.
Reporter | ||
Comment 1•25 years ago
|
||
Reporter | ||
Comment 2•25 years ago
|
||
Reporter | ||
Updated•25 years ago
|
Summary: ScrollFrameIntoView and SCROLL_ONLY_IF_NOT_FULLY_VISIBLE → ScrollFrameIntoView and SCROLL_IF_NOT_VISIBLE
Reporter | ||
Comment 3•25 years ago
|
||
Maybe I was not clear in what I wanted... In short, I would not like the screen to scroll horizontally if even a part of the target frame was visible in the view (and part was not). Currently even if a small part of the frame is outside the view, we scroll. The patch adds code to ScrollFrameIntoView to handle this. I also changed one caller, in the GoToAnchor. Other places where this occurs is in search etc. The test case has one line that is extremely long. You should resize your window so that id1 is completely outside of the view, oldscroll is part visible and part outside and noscroll is totally inside the view. Then try the different links. The oldscroll link shows the difference in behaviour.
What you're describing in the first part of the bug report is not true. What Gecko does is scroll horizontally the minimum amount in order for the target to be fully visible. This is also what IE does, and is better than what the 4.x Netscape browsers do which is typically to scroll all the way to the right edge of the window
I can see your point, but it's not clear what you propose is any better. It's different than our 4.x browser and IE which is bad, because it's not backwards compatible Your proposal assumes that what has been scrolled off on the left is more important than the entire target. I don't know that that is true. Unless there is a very compelling reason to change our current behavior I don't see why we should. Marking WONTFIX
Reporter | ||
Comment 7•25 years ago
|
||
I can live with wontfix for the general behaviour, but could you still check in the code that enables my behaviour, not any callers? I need this behaviour in a system we developed for a customer. If there was code that could do this on request I'd only need to call that code. As it is now I am required to mess with the baseline code.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 8•25 years ago
|
||
Based on troy's comments, marking as verified won't fix.
Assignee | ||
Updated•25 years ago
|
Status: VERIFIED → REOPENED
Assignee | ||
Updated•25 years ago
|
Assignee: troy → rods
Status: REOPENED → NEW
Assignee | ||
Comment 9•25 years ago
|
||
After talking to troy I am going to reopen this, I need sort of this same thing for gfx widgets.
Assignee | ||
Comment 10•25 years ago
|
||
reassigning to me
Comment 11•25 years ago
|
||
Clearing WON'TFIX resolution due to reopen.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M14
Assignee | ||
Comment 12•25 years ago
|
||
setting milestone to M14
Assignee | ||
Comment 13•25 years ago
|
||
The code is in and it works and is tested for form controls, I did not change anything to do with links.
Status: NEW → ASSIGNED
Whiteboard: Fix in my tree
Assignee | ||
Comment 14•25 years ago
|
||
Fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 15•25 years ago
|
||
*** Bug 21176 has been marked as a duplicate of this bug. ***
Comment 16•25 years ago
|
||
Marking verified fixed in Jan 31 build per last comments.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•