Closed
Bug 1028696
Opened 11 years ago
Closed 11 years ago
m.welt.de jumps back to start of page with every scroll action
Categories
(Web Compatibility :: Site Reports, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: sfleiter, Unassigned, Mentored)
References
()
Details
(Keywords: reproducible, Whiteboard: [country-de][jsissue][contactready])
What I did:
1. open m.welt.de on android
2. scroll down exactly once
(touch with thumb and move it up once)
3. remember current position
4. scroll down again and watch screen
What happened:
* With the start of the second scroll movement the page
jumps to the top before it starts scrolling.
* So if you try to scroll to the bottom of the page this is
(nearly) impossible.
* The site is unusable because of this.
What I expected to happen:
* The second scroll movement should start from current position
as on every other page.
welt.de is ranked 34 in Germany.
Works on:
* Chrome for Android
Does not work:
* Firefox for Android 30
* Firefox for Android trunk (366b5c0c02d3)
If this is a Tech Evangelism bug 969842 and this one could probably be
communicated at once.
Updated•11 years ago
|
Component: General → Graphics, Panning and Zooming
Comment 1•11 years ago
|
||
I was able to reproduce this on trunk (Nightly 06.23) on my Nexus 5. CC'ing Web Compat.
Keywords: reproducible
Whiteboard: webcompat
Comment 2•11 years ago
|
||
As far as I can tell this is the web content calling scrollTo on touchdown.
Component: Graphics, Panning and Zooming → Mobile
Product: Firefox for Android → Tech Evangelism
Comment 3•11 years ago
|
||
Seems somebody is trying to work around a bug in specific webkit versions and happen to run the wrong code path in Firefox? This and the related code in script.end.min.js is the culprit:
canBeFilledWithPoly = 'ontouchmove' in doc,
overflowProbablyAlreadyWorks = 'WebkitOverflowScrolling' in docElem.style || (!canBeFilledWithPoly && w.screen.width > 1200) || (function () {
var ua = w.navigator.userAgent,
webkit = ua.match(/AppleWebKit\/([0-9]+)/),
wkversion = webkit && webkit[1],
wkLte534 = webkit && wkversion >= 534;
return (ua.match(/Android ([0-9]+)/) && RegExp.$1 >= 3 && wkLte534 || ua.match(/ Version\/([0-9]+)/) && RegExp.$1 >= 0 && w.blackberry && wkLte534 || ua.indexOf(/PlayBook/) > - 1 && RegExp.$1 >= 0 && wkLte534 || ua.match(/Fennec\/([0-9]+)/) && RegExp.$1 >= 4 || ua.match(/wOSBrowser\/([0-9]+)/) && RegExp.$1 >= 233 && wkLte534 || ua.match(/NokiaBrowser\/([0-9\.]+)/) && parseFloat(RegExp.$1) === 7.3 && webkit && wkversion >= 533);
}) (),
They should probably make sure overflowProbablyAlreadyWorks is also set to true in Firefox.
Mentor: hsteen
Whiteboard: webcompat → [country-de][jsissue][contactready]
Comment 4•11 years ago
|
||
(In reply to Hallvord R. M. Steen from comment #3)
> Seems somebody is trying to work around a bug in specific webkit versions
> and happen to run the wrong code path in Firefox? This and the related code
> in script.end.min.js is the culprit:
Looks like that code originates from Overflow.js: https://github.com/scottjehl/Overthrow/blob/master/overthrow.js
Comment 5•11 years ago
|
||
Maybe they just need to update their UA matches? https://github.com/scottjehl/Overthrow/blob/master/overthrow.js#L42
Reporter | ||
Comment 6•11 years ago
|
||
This seems to be fixed by changes to the site and works now with Firefox for Android 30 and nightly.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•7 years ago
|
Product: Tech Evangelism → Web Compatibility
Assignee | ||
Updated•2 years ago
|
Component: Mobile → Site Reports
You need to log in
before you can comment on or make changes to this bug.
Description
•