Closed webcompat-bot closed 2 years ago
Confirmed, this works as expected in Chrome Mobile.
<div class="col-sm-4">
<select id="contactOption" name="contactOption" class="special-select">
<option>-- please select --</option>
<option value="965ed902-5bcf-4a3f-bb06-29a6c00e4003">Delivery and General Queries</option>
<option value="e561f23b-a6e0-455c-ac69-cb655b98e08f">My Account and Sales Queries</option>
<option value="489f19b0-a09f-418e-b426-4b924618478b">Your Feedback</option>
</select>
</div>
Relevant styles (leaving out a bunch of rules):
main .special-select, main .styled-select {
height: 35px !important;
border: 1px solid #cdcdcd;
background: url(images/drop-down.png) right center no-repeat #fff;
margin-top: 0;
padding-left: 0;
-webkit-appearance: none;
-moz-appearance: none;
appearance: none;
}
select {
width: 100%;
padding-right: 40px;
background: 0 0;
line-height: 1;
margin-bottom: 0;
-webkit-appearance: none;
-moz-appearance: none;
appearance: none;
}
It looks like there's some intercepting of events. When I log touch and mouse events, we get a touchstart
, then a mousedown
is dispatched by page script, then a mousedown
event.
The mousedown
dispatch is coming from FastClick:
dispatchEvent! mousedown debugger eval code:9:9
HTMLElement.prototype.dispatchEvent debugger eval code:9:9 FastClick.prototype.sendClick
https://www.dxdelivery.com/bundles/js:1:2844
FastClick.prototype.onTouchEnd
https://www.dxdelivery.com/bundles/js:1:6075
r/<
https://www.dxdelivery.com/bundles/js:1:79
This is busted at least going back to 41, so not a recent regression.
Ah, I had missed touchend
in my logging script:
Oh wait... isn't it impossible for a synthetic event (event.isTrusted == false
) to open a select? How does Chrome do it.
(here's my debug script, fwiw:
(function dbgEvtListeners() {
['click', 'touchstart', 'touchend', 'touchmove', 'mousedown', 'mouseup'].forEach(function(evt){
window.addEventListener(evt, function(e){
console.log(e, e.type, ' being sent to ' + e.target.outerHTML);
}, true);
});
var origDispatchEvent = HTMLElement.prototype.dispatchEvent
HTMLElement.prototype.dispatchEvent = function(evt) {
console.error('dispatchEvent! ', evt.type);
return origDispatchEvent.call(this, evt);
}
console.error('evt debugging ready');
})()
I don't see a mousedown
dispatch in Chrome Mobile, but a regular touchstart
-> touchend
-> mousedown
->mouseup
-> click
sequence.
(and note all those events are trusted)
This also reproduces in RDM... but the behavior is a little different. 🈂️
After mousedown
we get a trusted click
on the <option>
, which closes it I guess?
Running into some roadblocks...
https://github.com/devtools-html/debugger.html/issues/4412 https://github.com/devtools-html/debugger.html/issues/4411
OK, so FastClick is conditionally loaded in https://www.dxdelivery.com/scripts/scripts.min.js
/Android|webOS|iPhone|iPod/i.test(navigator.userAgent) && (device = !0,
$.getScript("/scripts/fastclick.min.js", function() {
FastClick.attach(document.body)
})),
Oh wait... isn't it impossible for a synthetic event (event.isTrusted == false) to open a select? How does Chrome do it.
This might be related: https://github.com/ftlabs/fastclick/issues/497
@RByers is it possible for wideViewportQuirkEnabled
to be true for non-WebView Chrome Mobile? I'm trying to understand why this select menu works in Chrome Mobile and fails in Firefox Mobile.
(edit: nevermind, I found the issue (I think!) -- thanks!)
Ah wait, hang on:
FastClick.notNeeded() returns true in Chrome Mobile (61), due to the site's meta viewport:
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=0" />
Some history here:
The patch that broke this for Firefox (to workaround an issue reported against Chrome/Android):
https://github.com/ftlabs/fastclick/pull/163
And here's an unmerged PR (from 4 years ago) to fix it, scoping it to Chrome on Android (rather than Android):
https://github.com/ftlabs/fastclick/pull/190
But ftlabs/fastclick#497 points out, that wouldn't fix the issue for Chrome Mobile anyways, since they disallow untrusted mouse events to open a select now.
Sort of a mess. If you look at the repo history... it's effectively unmaintained (save a few recent commits, one of which discourages people from using it).
@denschub do we have more issues like this? Do we just advocate having the site patch FastClick themselves? This site seems small enough that hacking around it at the sitepatch or Gecko level isn't worth it (not in top 100K)... unless this issue is more widespread.
OK, if they add a needsclick
class to the <select>
, FastClick won't screw it up:
https://github.com/ftlabs/fastclick/blob/master/lib/fastclick.js#L253
testpage: https://miketaylr.com/bzla/select-fastclick.html
I suggest we attempt outreach on this, and if it turns out to be a larger issue, attempt more dramatic things.
@adamopenweb could you try to find a contact here? thanks.
Reaching out to Kevin Toon, IT Services Director. https://www.linkedin.com/in/kevintoon/
@miketaylr
do we have more issues like this? Do we just advocate having the site patch FastClick themselves? This site seems small enough that hacking around it at the sitepatch or Gecko level isn't worth it (not in top 100K)... unless this issue is more widespread.
Actually, yeah. FastClick is used to remove a tapping delay on older systems, but it's actually not needed. In theory, they can remove it completely. We do have some other FastClick related issues, including:
All of them are on sitewait. Tom provided some details on these issues, and this seems pretty much like a duplicate. I wouldn't call the sites affected super important, except for GoTransit, but that's a different story. I'm also not sure if we could actually do a Gecko fix if they are simply checking UAs, but I can look into that if needed.
(I forgot to mention the other obvious fix for this issue, they can update their copy of FastClick to the latest version, because it adds a UA sniff for Firefox to return early).
Exactly, there's NO good reason to be using FastClick on ANY modern browser AFAIK, it's nothing but pain compared to just disabling the click delay via one of the finally standard mechanisms.
Exactly, there's NO good reason to be using FastClick on ANY modern browser AFAIK, it's nothing but pain compared to just disabling the click delay via one of the finally standard mechanisms.
+1 to that.
And another one #12793
I retested the issue and it is still reproducible on my side.
Tested with: Browser / Version: Firefox Nightly 68.10a1 (2019-08-11), Firefox Preview 1.2.0 (Build #12181645) Operating System: Huawei P10 (Android 8.0) - 1080 x 1920 pixels (~432 ppi pixel density)
I was able to reproduce the issue. I was able to trigger the selection menu once, but after many attempts, and sometimes this process is not successful.
We appreciate your report. I was able to reproduce the issue.
Tested with: Browser / Version: Firefox Nightly (2015810955-🦎90.0a1-20210516091748🦎) Operating System: Samsung A51 (Android 11) -1080 × 2400 pixels 20:9 aspect ratio (~405 ppi density)
Notes:
The layout has changed, and the drop-down menu is no longer available.
Tested with: Browser / Version: Firefox Nightly 101.0a1 (🦎 101.0a1-20220418091627) Operating System: Google Pixel 5 (Android 12) - 1080 x 2340 pixels, 19.5:9 ratio (~432 ppi density), Samsung Galaxy S8 (Android 9) - 1440 x 2960 pixels, 18.5:9 ratio (~570 ppi density)
[inv_16/2022]
URL: https://www.dxdelivery.com/contact/
Browser / Version: Firefox Mobile 58.0 Operating System: Android 8.0.0 Tested Another Browser: Yes
Problem type: Site is not usable Description: Drop-down menu does not work Steps to Reproduce: Found this page while trying to contact the company. You must select an option from the drop-down menu first, but no matter where I tap on it, the menu does not appear
From webcompat.com with ❤️