1926259 - www.google.com - The "Hamburger" menu button does not work

Status: NEW

(Web Compatibility :: Site Reports, defect, P1)

Description

[Raul Bucata]

Environment:
Operating system: Android 11
Firefox version: Firefox Mobile 133.0

Preconditions:
Account is signed out

Steps to reproduce:

1. Navigate to: https://www.google.com/webhp?client=firefox-b-m&channel=ts
2. Tap on the burger menu and observe

Expected Behavior:
Options are opened

Actual Behavior:
The button does not respond to touch

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in Firefox Nightly, and Firefox Release
• Does not reproduce in Chrome

Created from https://github.com/webcompat/web-bugs/issues/143014

Comment 1

[Raul Bucata]

Attachment: Screenshot_29.png

Comment 2

[Dennis Schubert [:denschub]]

This works fine for me right now in the current Nightly build. Maybe this was something temporary? can you confirm this is still broken for you, please?

Comment 3

[Raul Bucata]

This reproduces for us on the latest builds of Firefox Nightly and Release, on all Android devices available for testing

Comment 4

[Sean Feng [:sefeng]]

I can repro, looking at this

Comment 5

[Sean Feng [:sefeng]]

I think we should also reach to google about this. So I see they deliver different code for 131 and 134 for that Search Settings.
131

<div jscontroller="Bevgab" aria-label="Search settings" jsdata="yiZYyd;_;AWzIYE" role="dialog" jsaction="rcuQ6b:npT2md;HzrNx:x097hd">

134

<div jscontroller="HoZvlf" id="og-te" aria-label="Search settings" jsaction="rcuQ6b:npT2md" data-ved="0ahUKEwiqzvrzycWJAxUXDTQIHRUlOfgQmpcCCAI">

I also compared the execution of the javascript a bit between 131 and 134, and see the code runs differently between them, especially the following function isn't executed for 134, which I believe the code to show the settings.

      gF.prototype.Ma = function () {
        var a = this;
        this.Ms = !1;
        this.jpa.setAttribute('aria-expanded', 'true');
        _.jl(this.container, 'display', 'block');
        _.jl(document.body, 'overflow', 'hidden');
        requestAnimationFrame(
          function () {
            kmd(a, 0);
            _.jl(a.Aa, 'opacity', 0.999);
            _.Dl(a.container, 'hidden');
            var b = a.Oa('QA0Szd');
            a.nfa.open(b, _.vn(b, 'a'))
          }
        );
        _.Du([new _.Rm(this.container, 'show')], {
          triggerElement: this.jpa
        });
        mmd(this)
      };

I haven't seen evidences for web-compat. So it's better if we can get some words from google.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Sean Feng [:sefeng] from comment #5)

I think we should also reach to google about this. So I see they deliver different code for 131 and 134 for that Search Settings.

FWIW, I can reproduce this bug at least as far back as Nightly 125.0a1 2024-03-01 -- the top-left hamburger-menu and the top-right "Bento" app-menu do nothing when I tap them, in current Nightly and release as well as that^ pretty-old Nightly. (If I test Nightly 2024-02-01, i.e. another month back, I get a different older experience for google.com where this isn't reproducible [and there's no bento-button])

So I don't think this has to do with a recent change (or version-number-based-difference) in 131 vs 134. But maybe in comment 5, sefeng was (un)lucky enough to be getting some A/B testing from google, and he got one treatment in Firefox 131 vs the other treatment in 134? (Or maybe Google was in the process of doing a version-gated rollout and they've since lowered the version threshold.)

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: screencast showing the hamburger/bento buttons not working until I toggle Chrome Mask (to switch UA string.)

Comment 8

[Daniel Holbert [:dholbert]]

This does work in Nightly when I toggle the slider in our "Chrome Mask" diagnostic extension -- see screencast that I just attached, where I'm just visiting the not-signed-in version of https://www.google.com/ (just that URL, no query-params or anything), in Firefox Nightly 134.0a1

So, this is definitely caused by the code-that-Google-sends-specifically-to-browsers-that-say-they-are-Firefox.

Comment 9

[Daniel Holbert [:dholbert]]

I sent a message to our Google contacts to see if they can fix this.