Closed Bug 980635 Opened 8 years ago Closed 8 years ago

GMail's app permission screen doesn't adapt well to smaller screens, Accept button disappears


(Web Compatibility :: Mobile, defect, P2)

Gonk (Firefox OS)


(Not tracked)



(Reporter: guigs, Assigned: karlcow)


(Blocks 1 open bug, )


(Whiteboard: [fxos-bug-bash-1.4] [country-all] [sitewait])


(1 file)

Build Information

Device: Buri
Build ID: 
Platform Version: 30.0a1



Steps to Reproduce

1. start factory
2. go to import contacts ans select google
3. sign in then go to the page to ask to manage contacts
4. The accept should show on the screen
Expected Results
have a button on that is visible

Actual Results
you have to scroll to the right to accept the oauth

Other Notes
maybe have a custom accept form? 

Reproduction Frequency:
Assignee: nobody → english-us
Component: Gaia → English US
Product: Firefox OS → Tech Evangelism
Assignee: english-us → nobody
Component: English US → Mobile
Duplicate of this bug: 980634
Can someone explain what

> 1. start factory

Unfortunately it's hard to tell exactly what URL it is and what markup is sent (it's not a normal browser window) but hopefully the attached screenshot will be useful. I assume they use this app permission screen in several (mobile) contexts and want to make sure it works on mobile..
Summary: On start up when importing google contacts, the accept api button is off the screen → GMail's app permission screen doesn't adapt well to smaller screens, Accept button disappears
Whiteboard: [fxos-bug-bash-1.4] → [fxos-bug-bash-1.4][contactready]
Duplicate of this bug: 980737
This problem causes the user operation is very inconvenient,and It also can not move screen when slide in blank space in this page.
blocking-b2g: --- → 1.3?
It's an important issue, yes. We should talk to Google ASAP, and hope we can find a good contact..
Severity: normal → critical
Priority: -- → P2
(In reply to from comment #6)
> This problem causes the user operation is very inconvenient,and It also can
> not move screen when slide in blank space in this page.

TE problem, which is something we will not block on, as it's not part of core code.
blocking-b2g: 1.3? → ---
Contacted Alex (google).
Assignee: nobody → kdubost
Whiteboard: [fxos-bug-bash-1.4][contactready] → [fxos-bug-bash-1.4] [country-all] [sitewait]
So Google has answered very quickly. Quite cool. This was the answer today.

> Our approval page failed to recognize these UAs as mobile device.
> So the min-width is added, which causes this bug.
> Will change our code.

Let's check later so we can change the status.
Duplicate of this bug: 971931
Hi Karl, do we have any status updates from Google, or know if they are still working on this issue?

I also noticed today that the same behavior happens when importing a Google Calendar. Should I open a new bug for that, or is this one enough to cover both scenarios?

Flags: needinfo?(kdubost)
about the second part. No need to open an individual bug for each accept because it's just on Google Accounts and the accept $SOMETHING Authorization.

About the first part. It depends on the individuals. Some companies tell us when it is fixed, some we discover when testing again. There is no unique way. I usually tend to not harass people. Note that it has only be one week. :) To give you an example, we have a 1 year pending bug for ebay with a planned resolution in Q2 2014 and another one with Microsoft as old with a planned resolution in July 2014. :)

So it might come but not as fast as you would like. :)
Flags: needinfo?(kdubost)
Duplicate of this bug: 957796
Hi Karl,

Thanks for the status update and for providing some insight. I really hope that it doesn't take a year to fix this issue since again, it will be very visible and affect "all" of the users who go through the Import Contacts and Import Calendar from Google.

I will also reiterate what I mentioned in the bug 971931 that I opened: this issue does *not* happen in Firefox OS version 1.1. Once the user enters the credentials to access the Google account, the Import flow begins immediately, without prompting the user to accept. So again, there is definitely something different happening in Firefox OS version 1.3.

Is this a regression, or is there a particular reason why we now redirect the user to Google's "Accept" permissions page?

Hopefully someone will be able to provide more details.

- Ralph

First read comment #10 again :) Google has been contacted. 

The time it takes to resolve these issues are out of our control. Nagging too often will often create the opposite result that the one you want to achieve. It's also possible that Google decides to not fix the issue. :)

For Firefox OS 1.1 and Firefox OS 1.3, this is interesting.
Do you have the two devices under your hand?
Could you test again? 

1. erase all cookies for each test.
2. repeat the same sequence of actions.
3. Share the UA string for each of them.

Flags: needinfo?(rdaub)
Hi Karl,

I'm sorry, I didn't mean to imply nagging anyone as I understand the negative result that can have. :)

Because of the reach that this bug will have, what I was hoping is that we might look for creative ways to resolve it - either by investigating a possible regression, or by offering Google that we submit a patch ourselves. I don’t know if the latter would be possible, but if it is, I’m sure there would be contributors that would be up for the challenge. 

My concern is that this bug would end up ignored at Google and remain an open issue through future updates and versions of Firefox OS. I realize this is not a critical bug, but it affects all users who use this feature, and it makes the feature look broken. The average new smartphone user wouldn’t know or care whose fault it is.

Hopefully we can pinpoint a regression on the system, and something that we can fix ourselves. It would be even better if we could skip the "Accept Permissions" screen altogether, like it happens on v1.1 when importing contacts.

For the testing, I was able to replicate this issue on v1.3, but not on v1.1.

I did a factory reset and went through the First Time Use experience on the ZTE Open v1.1, LG Fireweb 1.1, ZTE Open C v1.3, and Geeksphone Keon v1.3. 

v1.3 showed the bugged “Accept Permissions” page
v1.1 skipped the Permissions screen and went directly to the Import Contacts flow.

When importing Calendar, both v1.1 and v1.3 showed the "Accept Permissions" page

ZTE Open (Ebay) and LG Fireweb v1.1:
1. Reset device
2. Go through First Time Use experience. 
3. Log in to Wi-Fi. 
4. Choose to import contacts from Google.
5. Enter credentials.
6. Message appears temporarily - "Please hold on. We are connecting to obtain your friend list”
7.  List of friends is shown.
8. Select friends and import.
9. If I leave the First Time Use experience and import contacts directly through the Contacts app, the same behavior happens.
10. If I import the Calendar, the “Accept Permissions” screen appears.

ZTE Open C and Geeksphone Keon v1.3:

1. Reset device
2. Go through First Time Use experience. 
3. Log in to Wi-Fi. 
4. Choose to import contacts from Google.
5. Enter credentials.
6. Screen appears with “This app would like to: Have offline access” and Cancel button.
7. Tap cancel.
8 . Page turns blank, with nothing loading. 
9. Tap the blue ‘X’ on the top left to leave the blank page.
10. Choose to import contacts from Google again.
11. Same confirmation page shows up again.
12. If the user doesn’t give up before then, he may realize that he can drag the screen to the right.
13. If I import the Calendar, the “Accept Permissions” screen also appears.

User Agents:
LG Fireweb v1.1 - Mozilla/5.0 (Mobile; LG-D300; rv:18.1) Gecko/18.1 Firefox/18.1
ZTE Open v1.1 - Mozilla/5.0 (Mobile; ZTEOPEN; rv:18.1) Gecko/18.1 Firefox/18.1
ZTE Open C v1.3 - Mozilla/5.0 (Mobile; Open C; rv:28.0) Gecko/28.0 Firefox/28.0

Please let me know if there is anything else that I or other contributors might be able to help with, or if there’s any information that might help investigating this issue. I also have other devices that I could test, or flash different versions on the Keon if necessary.

- Ralph
Flags: needinfo?(rdaub)
Thanks Ralph. This is very helpful.
(A tear at "Open C". This should not happen. This not following our recommendation to vendors. :/)

The "Geeksphone Keon v1.3" user agent string will be: "Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0" so I can see two possible sources for the issue:

1. User Agent sniffing based on the number (different behavior in between 18.1 and 28.0)
2. Implementation of a feature in 1.3 that Google is using for creating the accept screen

One last test that could be done to invalidate the hypothesis 1 would be to change the user agent string on 1.3 to be "Mozilla/5.0 (Mobile; rv:18.1) Gecko/18.1 Firefox/18.1" and sees if we have the behavior detected of 1.3 or 1.1. 

To answer:

> "or by offering Google that we submit a patch ourselves." 

I asked this same question a couple of months ago (in February in a F2F meeting). And I was told that:

> "It can help to understand the issue, but it would not help 
> getting a resolution. The decision to fix something is 
> independent of knowing what the issue is."
Flags: needinfo?(rdaub)
Hi Karl,

I am not sure how I can change the system's User Agent string on my ZTE Open C or on my Geeksphone Keon. Do you have any information or leads on how I may be able to do this for further testing?

Thanks in advance,
- Ralph
Flags: needinfo?(rdaub) → needinfo?(kdubost)
Duplicate of this bug: 1003394
to change the user agent it has to be done using the UA override mechanism.
see Bug 1015045#c21

The issue is I don't know what domains the mail and contact apps are requesting.
Flags: needinfo?(kdubost)
Hi Karl,

Thanks for the links and explanation. Unfortunately, at this time, these configurations and overrides are beyond my comprehension and would take too many cycles for me to successfully run these tests and comparisons. I don't know if there is anything else I can do to help at this point. 

With that being said, there remains a difference in the Import process between version 1.1 and later versions, with version 1.1's Import process having less steps and being more user friendly.

- Ralph

understood. Could you do a last test? :)

* ZTE Open v1.1
* LG Fireweb 1.1
* ZTE Open C v1.3
* Geeksphone Keon v1.3

Could you go to and report the sizes for each devices. (not urgent).
Duplicate of this bug: 1028312
Hi Karl, here are the Width/Height results from testing these devices:

* ZTE Open v1.1 = 320/480 with devicePixelRatio=1
* LG Fireweb 1.1 = 320/480 with devicePixelRatio=1
* ZTE Open C v1.3 = 320/480 with devicePixelRatio=1
* Geeksphone Keon v1.3 = 320/533 with devicePixelRatio=1.5

I hope this helps. 

- Ralph
Duplicate of this bug: 1034843
Last status message from Google.

> Talked to the engineer who works on this, she will fix this in 2 weeks.
Message from Google.

> The fix has been pushed to production. Please verify. 

Could someone using this feature test? rdaub?
Flags: needinfo?(rdaub)
FWIW, the permissions page linked from bug 1034843 comment 5 still has "Accept" cut off in desktop Firefox, in "Responsive Design View" with 320x480 viewport-size.  (It's possible they serve something friendlier when they see the Firefox OS UA string now, though; not sure.)

that's normal. The responsive design view is sending the desktop user agent. You may have better chances with the Firefox OS simulator or the actual device. :)
Gotcha, ok.

Good news -- I can confirm that this is FIXED in the Firefox OS 2.0 Simulator, as well as on my Flame device (running the 1.3-based OEM build), when triggering the Contacts app's import-from-gmail UI. (Both of those used to be broken, per bug 1034843 comment 0.)
Closed: 8 years ago
Resolution: --- → FIXED
Flags: needinfo?(rdaub)
Thanks Daniel.
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.