web-bugs
web-bugs copied to clipboard
www.mercadolivre.com.br - "Browse" hamburger menu is not functional
URL: https://www.mercadolivre.com.br
Browser / Version: Firefox Mobile 107.0 Operating System: Android 12 Tested Another Browser: Yes Chrome
Problem type: Site is not usable Description: Buttons or links not working Steps to Reproduce: The hamburger menu doesn't work.
Browser Configuration
- gfx.webrender.all: false
- gfx.webrender.blob-images: true
- gfx.webrender.enabled: false
- image.mem.shared: true
- buildID: 20221013100028
- channel: nightly
- hasTouchScreen: true
- mixed active content blocked: false
- mixed passive content blocked: false
- tracking content blocked: false
From webcompat.com with ❤️
Thanks for the report, I was able to reproduce the issue.

Affected area:
<button class="nav-header-menu-switch" aria-label="Menu do usuário" aria-expanded="false" tabindex="8">
<span>
<span class="hamburger-top-bread"></span>
<span class="hamburger-patty"></span>
<span class="hamburger-bottom-bread"></span>
</span>
</button>
Note:
- The issue is not reproducible on Chrome.
- The issue is reproducible on Firefox regardless of the ETP status.
Tested with: Browser / Version: Firefox Nightly 107.0a1 (🦎 107.0a1-20221016093143), Firefox Release 105.2.0 (🦎 105.0.2-20221003135607) Operating System: Google Pixel 5 (Android 13) - 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)
Moving to Needsdiagnosis for further investigation.
[qa_42/2022]
The site uses relatively simple JS to show and hide the menu:
t.switch.addEventListener("click", function () {
"false" === this.ariaExpanded ? c() : d();
});
function c() {
n.classList.add("nav-header-menu-mobile-open"),
(t.switch.ariaExpanded = !0),
t.menu.focus({ preventScroll: !0 });
}
function d() {
n.classList.remove("nav-header-menu-mobile-open"),
(t.switch.ariaExpanded = !1),
t.switch.focus();
}
but unfortunately, Firefox does not support Element.ariaExpanded, so the entire logic breaks down.
That attribute is part of the WAI-ARIA spec, and there's quite a lot of them. There is a web-platform-test for it, which is very red in Firefox. And there is a Firefox bug to track the implementation on file as well: https://bugzilla.mozilla.org/show_bug.cgi?id=1769586
These attributes are, however, "just" a reflection of their DOM attribute counterparts, in this case aria-expanded. We could in theory ship a shim. We'd need both a getter and a setter, as the site is also writing those attributes via the ARIAMixin interface. From a quick search, I could also find that the site is using ariaLabel, ariaHidden, ariaModal, ariaHasPopup, and possibly others as well - so I'm not sure how feasible a shim would actually be, unless we shim all supported attributes, which would be... a lot. Given the high priority of the site, I'll set the needssitepatch label anyway just so we can explore that.
Given their frequent usage of these attributes, I'd guess that reaching out to them has a low chance of success (especially since it's already very clear they don't care about Firefox), so I'll close this as a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1769586 for now.
I realise this is a bit confusing, but that Bugzilla bug is for another part of ARIA reflection which isn't covered here. ariaExpanded, etc. is covered by https://bugzilla.mozilla.org/show_bug.cgi?id=1785412.
As https://bugzilla.mozilla.org/show_bug.cgi?id=1824980 was enabled in Nightly, the menu is working as expected, so we can remove the sitepatch label
Note that even though this is enabled in nightly, it won't be riding to beta and release just yet until some spec issues are resolved.