Closed
Bug 980635
Opened 10 years ago
Closed 10 years ago
GMail's app permission screen doesn't adapt well to smaller screens, Accept button disappears
Categories
(Web Compatibility :: Site Reports, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: guigs, Assigned: karlcow)
References
()
Details
(Whiteboard: [fxos-bug-bash-1.4] [country-all] [sitewait])
Attachments
(1 file)
51.92 KB,
image/png
|
Details |
Build Information Device: Buri Build ID: Platform Version: 30.0a1 Description [fxos-bug-bash-1.4] 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:
Updated•10 years ago
|
Assignee: nobody → english-us
Component: Gaia → English US
Product: Firefox OS → Tech Evangelism
Updated•10 years ago
|
Assignee: english-us → nobody
Component: English US → Mobile
Comment 2•10 years ago
|
||
Can someone explain what
> 1. start factory
means?
Comment 3•10 years ago
|
||
Comment 4•10 years ago
|
||
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]
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?
Comment 7•10 years ago
|
||
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
Comment 8•10 years ago
|
||
(In reply to wuww@tcl.com 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? → ---
Updated•10 years ago
|
Blocks: google.com
Assignee | ||
Comment 9•10 years ago
|
||
Contacted Alex (google).
Assignee: nobody → kdubost
Status: NEW → ASSIGNED
Whiteboard: [fxos-bug-bash-1.4][contactready] → [fxos-bug-bash-1.4] [country-all] [sitewait]
Assignee | ||
Comment 10•10 years ago
|
||
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.
Comment 12•10 years ago
|
||
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? Thanks!
Flags: needinfo?(kdubost)
Assignee | ||
Comment 13•10 years ago
|
||
Ralph, 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)
Comment 15•10 years ago
|
||
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. Thanks!! - Ralph
Assignee | ||
Comment 16•10 years ago
|
||
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. Thanks.
Flags: needinfo?(rdaub)
Comment 17•10 years ago
|
||
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. Thanks!! - Ralph
Flags: needinfo?(rdaub)
Assignee | ||
Comment 18•10 years ago
|
||
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)
Comment 19•10 years ago
|
||
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)
Assignee | ||
Comment 21•10 years ago
|
||
Ralph, to change the user agent it has to be done using the UA override mechanism. see Bug 1015045#c21 and https://groups.google.com/forum/#!msg/mozilla.compatibility/MrQQtOc7_x4/fUNzQvrgVXcJ The issue is I don't know what domains the mail and contact apps are requesting.
Flags: needinfo?(kdubost)
Comment 22•10 years ago
|
||
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
Assignee | ||
Comment 23•10 years ago
|
||
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 http://www.quirksmode.org/m/tests/widthtest.html and report the sizes for each devices. (not urgent).
Comment 25•10 years ago
|
||
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
Assignee | ||
Comment 27•10 years ago
|
||
Last status message from Google.
> Talked to the engineer who works on this, she will fix this in 2 weeks.
Assignee | ||
Comment 28•10 years ago
|
||
Message from Google.
> The fix has been pushed to production. Please verify.
Could someone using this feature test? rdaub?
Flags: needinfo?(rdaub)
Comment 29•10 years ago
|
||
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.)
Assignee | ||
Comment 30•10 years ago
|
||
Daniel, 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. :)
Comment 31•10 years ago
|
||
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.)
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
Flags: needinfo?(rdaub)
Assignee | ||
Comment 32•10 years ago
|
||
Excellent! Thanks Daniel.
Updated•5 years ago
|
Product: Tech Evangelism → Web Compatibility
Updated•1 month ago
|
Component: Mobile → Site Reports
You need to log in
before you can comment on or make changes to this bug.
Description
•