The user is unable to scroll on feedmusic.com on Yoga devices (caused by Modernizr.touch having different values in Firefox vs. Chrome, caused by -moz-touch-enabled)
Categories
(Core :: Panning and Zooming, defect, P2)
Tracking
()
People
(Reporter: rdoghi, Assigned: emilio)
References
Details
(Keywords: dev-doc-needed, site-compat)
Attachments
(4 files)
[Affected versions]:
Nightly 71.0a1
[Affected platforms]:
Platforms: Arm64
Steps :
- Launch the Firefox browser and reach www.feedmusic.com
- Scroll the page down.
Expected Results :
The user should be able to scroll down using a mouse wheel or the 2 finger touch method.
Actual Results :
The user is not able to scroll the page/text in any way except by clicking the text and dragging it upwards.
Reporter | ||
Updated•5 years ago
|
Comment 1•5 years ago
•
|
||
The site is doing something weird on touchscreens in Firefox. It changes the cursor to cursor: move
over the main content, and installs listeners that allow you to scroll by dragging. I'm guessing that disabling mousewheel and touch scrolling is related to this as well.
Comment 2•5 years ago
•
|
||
The site is definitely serving different content to Firefox vs. Chrome.
In Firefox, the following element is present in the DOM, but not in Chrome:
<div class="kinetic-active" style="position: absolute; top: 0px; left: 0px;
width: 100%; height: 100%; overflow: hidden; cursor: move;">
This element has a bunch of event handlers which cause the Firefox-specific behaviour.
Comment 3•5 years ago
|
||
The presence of the element seems to be related to the fact that Modernizr.touch
evaluates to true
in Firefox, but false
in Chrome.
cc'ing some webcompat folks -- does the above ring a bell at all?
Comment 4•5 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #3)
Modernizr.touch
evaluates totrue
in Firefox, butfalse
in Chrome.
I've confirmed that this happens with the latest version of Modernizr as well (though they have renamed the query from touch
to touchevents
).
STR:
- https://modernizr.com/
- Click "Add your detects"
- In the search box, type "touch"
- Click the (+) button next to "Touch Events"
- Click Build
- In the dialog that comes up, click "Open build in codepen.io"
- Open codepen's Console
- Type
Modernizr.touchevents
On a touchscreen laptop, in Firefox the answer is true
but in Chrome the answer is false
.
Comment 5•5 years ago
|
||
This is the test Modernizr is using for touch events:
Modernizr.addTest('touchevents', function() {
var bool;
if (('ontouchstart' in window) || window.DocumentTouch && document instanceof DocumentTouch) {
bool = true;
} else {
// include the 'heartz' as a way to have a non matching MQ to help terminate the join
// https://git.io/vznFH
var query = ['@media (', prefixes.join('touch-enabled),('), 'heartz', ')', '{#modernizr{top:9px;position:absolute}}'].join('');
testStyles(query, function(node) {
bool = node.offsetTop === 9;
});
}
return bool;
});
Comment 6•5 years ago
|
||
It's the second branch that's causing touchevents
to be true. I'm not quite sure what that second branch is doing.
Comment 7•5 years ago
•
|
||
@botond, assuming prefixes
is intended to be an array like this: ["-webkit-", "-moz-"]
The code is likely trying to (temporarily) add a stylesheet like this:
@media(touch-enabled),(-webkit-touch-enabled),(-moz-touch-enabled) {
#modernizr { top:9px;position:absolute }
}
And then test to see if #modernizr
is offset down by 9.
Which would be the case in Firefox when -moz-touch-enabled
works (also Chrome and any other browser where the CSS applies).
I have no idea if that actually means that touch events are enabled in Firefox, though. It seems likely that the CSS just doesn't apply in Chrome on a laptop+touchscreen, presumably because the CSS doesn't pass, while in Firefox it does. That could indicate a faulty Moderizr test and a likely interop issue (or maybe Firefox should also not apply that CSS in that case, I'm not sure).
Comment 8•5 years ago
|
||
I see, thanks.
Indeed, it looks like Firefox recognizes the -moz-touch-enabled
media query, but Chrome does not recognize any prefixed (or unprefixed) variant of touch-enabled
.
Emilio, I see you have a comment about potentially removing -moz-touch-enabled
. The bug the comment references has landed. Do you know if there's anything else blocking this removal?
Assignee | ||
Comment 9•5 years ago
|
||
Not really!
Assignee | ||
Comment 10•5 years ago
|
||
This is effectively superseded by the hover / any-hover media queries, which
actually are standard, and is also causing trouble in the wild.
Not even the browser fronted uses it, so we should be able to just remove it
everywhere at once.
Assignee | ||
Comment 11•5 years ago
|
||
There's no effort to disable it any time soon, so I don't think it's useful to
keep the pref around.
Assignee | ||
Comment 12•5 years ago
|
||
Servo doesn't use this flag or -webkit- prefixed media queries, so no point in
doing this conditionally.
Assignee | ||
Comment 13•5 years ago
|
||
We can deindent and simplify a bunch of this code now.
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 14•5 years ago
|
||
Comment 15•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/673c2d3025c5
https://hg.mozilla.org/mozilla-central/rev/3e6d7417194c
https://hg.mozilla.org/mozilla-central/rev/14e9efe2db1d
https://hg.mozilla.org/mozilla-central/rev/430c949e8c7f
Comment 17•5 years ago
|
||
Posted site compatibility note: https://www.fxsitecompat.dev/en-CA/docs/2019/moz-touch-enabled-media-feature-has-been-deprecated/
Comment 18•5 years ago
|
||
The commit message says “Hide -moz-touch-enabled media query in Nightly and Early Beta“ but the value is @IS_NOT_NIGHTLY_BUILD@
instead of negated @IS_EARLY_BETA_OR_EARLIER@
so I guess it’s still enabled even in early Beta?
Assignee | ||
Comment 19•5 years ago
|
||
D'oh, indeed.
Updated•5 years ago
|
Description
•