Open webcompat-bot opened 4 years ago
Thanks for the report, I was able to reproduce the issue.
Note:
Tested with: Browser / Version: Firefox Nightly Preview 200224 (🦎: 75.0a1-20200223093951), Firefox Beta 68.6b3 Operating System: Huawei P20 Lite (Android 8.0.0) - 1080 x 2280 pixels, 19:9 ratio (~432 ppi density), Samsung Galaxy S6 Edge (Android 7.0) - 1440 x 2560 pixels (~577 ppi pixel density)
Moving to Needsdiagnosis for further investigation.
These two are covering the content with a layer and make the clicks impossible to the layers underneath.
<div class="row maestro-middle">
<div class="clearfix"></div>
<div class="banner-middle maestro-banner-middlemobile" id="maestro-banner-middlemobile"></div>
</div>
.table-layout .row.maestro-middle {
margin-top: 10px;
margin-bottom: 10px;
background-color: transparent;
}
At the beginning I thought it was something like https://bugzilla.mozilla.org/show_bug.cgi?id=1256980, but it's not.
The overlay is here in Chrome too, but the click goes through
ah maybe it is. The block with the links has a z-index: 2
but not a position: absolute
, it uses relative
what do you think @dholbert ?
I'll try to make a reduced test case later.
Chrome's disregarding the z-index
here, and this behavior-difference is tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1573990.
Specifically, this element...
<div class="table-cell table-content"
style="position:relative;z-index:2;">
...has this styling inside of a media query:
@media(max-width:767px) {
[...]
.table-layout.content-layout .table-cell {
display: initial;
The initial value of display
is inline
, so this element end up with display:inline
in its computed style.
And we've got a disagreement with Chrome about how z-index
works on display:inline
elements (and in particular, whether their block-level descendants are affected or not), as tracked in the above-linked bug.
With display: initial
here, the site is really doing something weird -- I think the site is intending to reset the element to the display value that it would've originally had, disregarding other style rules, but in fact it's setting this container element to display:inline
which is certainly not what they want for a relatively-positioned wrapper element with z-index
on it.
The correct keyword to do that is revert
, not initial
. But unfortunately Chrome doesn't support the revert
keyword yet (as shown in the compat table on MDN), nor does EdgeHTML apparently, so we can't really suggest it as a replacement here. (The Chromium bug on adding that keyword is https://bugs.chromium.org/p/chromium/issues/detail?id=579788 , for the record.)
In the meantime, we might suggest that they consider using display:block
in the rule that I quoted above, instead of display:initial
(assuming that they would prefer all such elements to end up as blocks rather than as inlines). This change is sufficient to fix the problem, and doesn't seem to have negative fallout as far as I can tell.
it has been fixed by Chrome. https://bugs.chromium.org/p/chromium/issues/detail?id=579788
so revert
is possible.
I have contacted them.
This is still reproducible, but per https://bugzilla.mozilla.org/show_bug.cgi?id=1573990#c17 , Chrome changed to match our behavior here -- so I can reproduce this issue (links can't be tapped) in both Chrome and Firefox now.
(Tested in responsive design mode on desktop, for both browsers.)
URL: https://byggebolig.no/innhold/finn?q=Smart+dimmer
Browser / Version: Firefox Mobile 73.0 Operating System: Android Tested Another Browser: Yes
Problem type: Site is not usable Description: Unable to click links in search results. Steps to Reproduce: Scrolled past sponsored results and tried to click a link. Nothing happens.
Browser Configuration
From webcompat.com with ❤️