Closed
Bug 547307
Opened 16 years ago
Closed 15 years ago
Cannot reach the bottom of the page using keyboard (scrolling to the bottom, End, Page Down, arrow keys)
Categories
(Firefox for Android Graveyard :: Panning/Zooming, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: Aleksej, Assigned: mbrubeck)
References
()
Details
(Whiteboard: [MobFx1.1testday])
Attachments
(1 file, 1 obsolete file)
|
957 bytes,
patch
|
mfinkle
:
review+
|
Details | Diff | Splinter Review |
Build 1.9.2 20100219013601 on Debian GNU/Linux with xmonad.
Regression range: 2010011101 … 2010011201 (fixed: bug 537694, bug 537660)
Steps to reproduce:
1. Load a page which is long enough to be scrolled (http://ru.wikipedia.org/ is a better example than the Fennec's start page).
2. Press End or keep pressing Down or Page Down until scrolling stops.
3. Scroll down using the pointing device / touch pad.
Actual results:
At step 2, keyboard scrolling stops before reaching the end of the page.
At step 3, the end is reached using the pointing device.
Expected results:
The bottom of the page can be reached using keyboard.
| Reporter | ||
Updated•16 years ago
|
Component: Linux/Maemo → General
QA Contact: maemo-linux → general
| Assignee | ||
Comment 1•16 years ago
|
||
This seems to happen especially if the page is zoomed in. It looks like the keyboard scroll commands are still using the original scrollable area, not the zoomed in area. (If the page is zoomed out past the default level, there is different but related behavior.)
Assignee: nobody → mbrubeck
| Assignee | ||
Updated•16 years ago
|
tracking-fennec: --- → ?
| Assignee | ||
Comment 2•16 years ago
|
||
Bug 542480 is different but maybe related.
| Assignee | ||
Comment 3•16 years ago
|
||
There are two problems here:
1) Browser.scrollContentToBrowser does not use zoomLevel to translate content coordinates to screen coordinates, and
2) the <browsers>'s style.height is not changed when the zoomLevel changes, so even when the bottom of the page is visible in the <browser>, it might not be visible onscreen (because part of the <browser> might be offscreen).
Status: NEW → ASSIGNED
Component: General → Panning/Zooming
OS: Linux → All
QA Contact: general → pan-zoom
Hardware: x86 → All
| Assignee | ||
Comment 4•16 years ago
|
||
I tried out a sort of hacky patch to add a zoomLevel ratio to scrollContentToBrowser, and always set browser.style.height to window.innerHeight. But that won't work for horizontal scrolling. (We can't change browser.style.width without changing the layout.) Fennec really needs to handle scrolling actions itself in InputHandler.js, like vingtetun suggests in bug 542480 comment 1. Or re-enable SNAV.
Status: ASSIGNED → NEW
| Assignee | ||
Comment 5•16 years ago
|
||
This patch together with the patch in bug 479862 attachment 428336 [details] [diff] [review] solves most of the problem. There's still an issue when the height of the browser is greater than the window height, which I'll try to fix next.
| Assignee | ||
Comment 6•15 years ago
|
||
Rebased against latest mobile-browser.
As mentioned above, there are still some cases where this is broken - but this patch fixes the problem on a lot of sites that I use, including the "Skip to menu" link on http://ask.metafilter.com/ and all of the scrolling on http://google.com/reader/i
Attachment #440830 -
Attachment is obsolete: true
Attachment #455204 -
Flags: review?(mark.finkle)
Updated•15 years ago
|
Attachment #455204 -
Flags: review?(mark.finkle) → review+
Comment 7•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
| Reporter | ||
Comment 8•15 years ago
|
||
VERIFIED FIXED on trunk/20100708014849.
Still reproducible on 1.9.2/20100708013742.
Should this bug still be marked "Version: 1.9.2"?
| Reporter | ||
Updated•13 years ago
|
Status: RESOLVED → VERIFIED
Updated•12 years ago
|
tracking-fennec: ? → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•