Closed Bug 921536 Opened 7 years ago Closed 4 years ago

Google menu icon in the top-left corner in Firefox doesn't open a menu

Categories

(Web Compatibility :: Mobile, defect)

ARM
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 975444

People

(Reporter: marco, Assigned: karlcow)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [country-all] [serversniff] [sitewait])

Attachments

(5 files)

In the stock browser, the menu icon in the top-left corner actually opens a menu where you can switch between different Google services.
In Firefox, the menu icon is a link to a page that lists a set of apps to install through Google Play.
See Also: → 928512
Blocks: google.com
Confirmed. I will contact the usual person.
Hardware: All → ARM
Whiteboard: [country-all] [serversniff] [contactready]
Duplicate of this bug: 928512
Attached image google-top-menu.png
Top Left icon menu added as an attachment.
Not fixed.
Assignee: nobody → kdubost
Status: NEW → ASSIGNED
Problem affects both Firefox OS and Firefox on Android.
On Chrome Mobile Nexus, we get this markup for the button. 
(Google is also requesting to share location.)
  
   <a id="gbg" class="gbsi gbsv"></a>

On Firefox OS, we get this markup. 
(Google doesn't request the location.)

   <a class="gbsi gbsv" href="/mobile/" id="gbg"> </a>


The difference is happening on the click event on the top-left burger menu.
When clicking the slide menu is populated.
When faking the Chrome Mobile UA on Firefox OS or Firefox Android, we receive the chrome Markup and the interaction is working.

to note that I haven't found things breaking but the home page script which makes possible the sliding menu contains instances of 

* webkitTransitionEnd in
   V("webkitTransitionEnd","gb-main",Pa)
* webkitTransform in 
   (b.style.webkitTransform="",b.style.transform="")
 
I guess only the first one might break something. Hallvord, could you confirm?
Flags: needinfo?(hsteen)
This needs no more analysis, I think. The markup for the menu is simply omitted from the version Firefox on Android gets, if you spoof and get the right markup and JS it seems to work perfectly well.
Flags: needinfo?(hsteen)
Contacted Google.
Whiteboard: [country-all] [serversniff] [contactready] → [country-all] [serversniff] [sitewait]
Any news on this?
Seems the tablet UI offers a better search experience. I'm not sure whether this was true before the new tablet UI (in ffx 35+ iirc?) because I only just noticed the improvement when checking on a nexus 7".

As in bug #847485 I checked on the android emulator (android 4.4.2 for x86):

* Emulated phone - a newly created "Nexus 4" with downloaded aurora 37.0a2 (2015-01-26):
-> google.co.uk has a top-left menu that is buggy as described abouve (search results pages instead have a  "More" option on the white menu bar that works similarly)
* Emulated tablet - an existing "10.1" WXGA" device with firefox beta 35
-> google.co.uk and the search results have a black menu bar at the top of the page that offers google services as well as a white menu bar below the search box that offers many/all of the search customization options I get from desktop firefox (bug #1047854).

As noted in the other bug this isn't an apples to apples comparison but it does look like phone vs. tablet form factor is the difference.
(In reply to Oliver Henshaw from comment #10)
> As in bug #847485 I checked on the android emulator (android 4.4.2 for x86):
That should be bug #847845
(In reply to Oliver Henshaw from comment #9)
> Any news on this?

Thanks Oliver to shake the tree.
First of all this bug is about Firefox on Android. Tested with the UA pattern:

    User-Agent: Mozilla/5.0 (Android; Mobile; rv:36.0) Gecko/36.0 Firefox/36.0


2013-09-28: The bug was opened.
2013-12-07: It was reported to Google. They acknowledged it.
2014-07-08: I've sent a reminder.

I tested this morning on a device and it seems to be fixed for the US and the Japanese versions.
The top right icon gives access to settings and services
The top left icon gives access to categories.

I will close this as RESOLVED. Hallvord could you verify that I'm not the only one? 

If there are issues with other form factors (such as tablets), or different OSes (such as Firefox OS), please open a separate bug. 

Also we got http://webcompat.com/ for bug web compatibility bugs reporting.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
In Italy, it's still as comment 0.
Attached image news-google-it.png
(In reply to Marco Castelluccio [:marco] from comment #13)
> In Italy, it's still as comment 0.

For news.google.it, I get the right site working as planned.
See the attachment
news.google.it asks you to download an app, if you decline it brings you to the right site.

The problem is with www.google.it, where the menu button works differently in Firefox for Android and Chrome. In Firefox for Android, it opens a page with a list of Google apps you can install. In Chrome, it's a menu like the news.google.it one.

(As a side note, the images on www.google.it are blurry in Firefox, not blurry in Chrome)
Attached image Firefox for Android
Attached image Chrome
The two screenshots were taken after tapping on the Google menu icon
Oh wait. I was mixed up in my emails. Sorry about that.
I was looking at news.google.com and not google.com
Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Firefox Mobile 28 (the oldest version I can run on the x86 emulator) on tablet form-factor: WORKS

So google search does seem to be offering a working page to tablet users, fwiw.
Most recent layout differences in between Google search on chrome and Firefox for this menu to switch apps. The screenshot for chrome has been taken on Gecko with Chrome UA. So it is working :) And they could just send us the Chrome version.
If Google was sending us what they send to Chrome. It would basically work except for one thing when loading images. This script in the main html depends on `webkitAnimationDelay` and `webkitAnimationEnd`

Note that with `layout.css.prefixes.webkit; true` This is working.


```
(function () {
  (function () {
    if (!google.xjsir) if (google.q && google.q.iere) {
      for (var d = document.querySelectorAll('#topstuff,#fc,.ichpcnt,#fsad'), a = 0; a < d.length; a++) d[a].classList.add('qs-css-m');
      var c = document.getElementById('rg');
      c ? (c.style.webkitAnimationDelay = '150ms', c.classList.add('qs-css-m'), c.addEventListener('webkitAnimationEnd', function () {
        c.style.webkitAnimationDelay = '';
        document.documentElement.classList.remove('qs-css-a');
        if (google.isr && google.isr.layout && google.isr.layout.getResultsForPage) {
          var a = google.isr.layout.getResultsForPage(0);
          if (a && a.length) for (var d = 0, b; b = a[d++]; ) if ((b = b.querySelector('.rg_i')) && (!b.src || 'string' != typeof b.src)) {
            var e = b.getAttribute('data-src');
            e && (b.src = e)
          }
        }
        google.q.sqprt && google.q.sqprt()
      }))  : (google.q.sqprt && google.q.sqprt(), document.documentElement.classList.remove('qs-css-a'))
    } else document.documentElement.classList.remove('qs-css-a')
  }) ();
}) ();

```
Previous comment is related to the search images part on Firefox Android. More related to https://bugzilla.mozilla.org/show_bug.cgi?id=921532

It's because I'm trying to access if they can send us the Chrome version.
> Note that with `layout.css.prefixes.webkit; true` This is working.

Cool. `webkitAnimationDelay` and `webkitAnimationEnd` support come with that, so either way we should be able to have this working pretty soon. \o/ (even cooler if Google is willing to use unprefixed events).
Mike, 

any news about webkitAnimationDelay and webkitAnimationEnd  
Is there a bug number?
Flags: needinfo?(miket)
Karl: see Bug 1236979 for webkitAnimationEnd events, et al. -webkit-animation-delay is aliased and behind the layout.css.prefixes.webkit pref, shipping in 49 (see Bug 837211).
Flags: needinfo?(miket)
Depends on: 1236979
I think we can close this (either as FIXED or WFM -- I'm able to click on the menu, but it directs to a different page for me, rather than showing the previous menu). But all the blocker bugs are fixed.
Status: REOPENED → RESOLVED
Closed: 6 years ago4 years ago
Resolution: --- → WORKSFORME
(In reply to Mike Taylor [:miketaylr] from comment #27)
> I think we can close this (either as FIXED or WFM -- I'm able to click on
> the menu, but it directs to a different page for me, rather than showing the
> previous menu). But all the blocker bugs are fixed.

Isn't the issue in this bug exactly this?
There shouldn't be a difference in the experience between Chrome and Firefox, currently the experience with Chrome is better.

Moreover, the links in the Chrome menu sometimes bring you to the web version (e.g. m.youtube.com), in the Firefox page they open a Google Play page to install the app.
(In reply to Marco Castelluccio [:marco] from comment #28)
> (In reply to Mike Taylor [:miketaylr] from comment #27)
> > I think we can close this (either as FIXED or WFM -- I'm able to click on
> > the menu, but it directs to a different page for me, rather than showing the
> > previous menu). But all the blocker bugs are fixed.
> 
> Isn't the issue in this bug exactly this?
> There shouldn't be a difference in the experience between Chrome and
> Firefox, currently the experience with Chrome is better.

I'm sorry, I misunderstood based on the title and coming from one of the dependencies. 

I think we can consider this a dupe of Bug 975444, which is basically about Google sending Fennec Tier 1 content. See https://bugzilla.mozilla.org/show_bug.cgi?id=975444#c17 where Karl has asked Google for this specifically.
Resolution: WORKSFORME → DUPLICATE
Duplicate of bug: 975444
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.