Follow up of Bug 1082444. User can see "Check Settings" button and it cannot work after on/off network



Firefox OS
3 years ago
2 months ago


(Reporter: whsu, Assigned: alive)


Gonk (Firefox OS)

Firefox Tracking Flags

(b2g-v2.0 affected, b2g-v2.0M affected, b2g-v2.1 affected, b2g-v2.2 affected)


(Whiteboard: [LibGLA,TD123196,QE3, B][p=1], URL)


(2 attachments)



3 years ago
+++ This bug was initially created as a clone of Bug #1082444 +++

@ Description:
  This bug happened on FxA "Privacy Notice" page.
  After user taps "Privacy Notice" on FxOS account page with internet access, and then taps "Mozilla Privacy Policy" on the "Privacy Notice" page with no internet access.
  User can see "Check Settings" button and it cannot work.

@ Prerequisite:
  Connect to WIFI network

@ Tester's Action : 
  1. Tap [Settings] icon on Home screen.
  2. Tap [Firefox Accounts] menu in settings app
  3. Tap [Create account or sign in] button
  4. Tap "Privacy Notice" on FxOS account page
  5. Disable network via status bar
  6. Tap "Mozilla Privacy Policy" link on the "Privacy Notice" page
  7. Tap [Check settings] button 
@ Detailed Symptom:
  The [Check settings] button cannot work

@ Expected :
  Tapping [Check settings] button launches settings app

@ Build information:
 - Gaia-Rev        f76014fd2c7528493b90d759c68ec3070233d094
 - Gecko-Rev
 - Build-ID        20150106000204
 - Version         32.0
 - Device-Name     flame
 - FW-Release      4.4.2
 - FW-Incremental  eng.cltbld.20150106.034857
 - FW-Date         Tue Jan  6 03:49:08 EST 2015
 - Bootloader      L1TC00011880


3 years ago
No longer depends on: 1082444

Comment 1

3 years ago
[Blocking Requested - why for this release]:

A functional defect.
blocking-b2g: --- → 2.0?
Keywords: verifyme


3 years ago
status-b2g-v2.0: --- → affected
status-b2g-v2.0M: --- → affected
status-b2g-v2.1: --- → affected
status-b2g-v2.2: --- → affected
an follow up of bug 1082444, which is tagged for 2.0 and fixed from 2.0 (approved) to 2.2, thus tend to be tagged for 2.0 as well in coming Triage.
[Blocking Requested - why for this release]:

[Triage] considering 2.0 timing and user impact, nom. to 2.1 instead.
blocking-b2g: 2.0? → 2.1?
The activity is opened but it still in background (it seems). I'm not sure about because this is happening, may it be because the settings calls to a settings activity. What I've noticed is that if you close the app and then you open it again, you'll see the activity requested before.

Any ideas about how to bring to the foreground the activity?
Flags: needinfo?(arthur.chen)
Jared, looks like you were helping on from which this is cloned. Can you give your input on this ? I feel its an edge case and not something we'd block 2.1 for although, it'll be great if we can fix this in 2.2
Flags: needinfo?(6a68)
Assignee: nobody → b.mcb
Created attachment 8548826 [details] [review]
Proposed patch

After a deep research, I've noticed that the Settings app is only handling the activity messages on startup. That's the origin of one of the issues. If the app is open and we click the "Check Settings" button, the app will not handle that message until we relaunch it.

I've implemented a first approach (I know the patch is ugly but is not the last version) which set up the activity handle from the startup. Once the message is received, we need to check if the Settings app is the current app in order to set up the navigation back when the user finish the required task.

To do this, I think we should send an event in order to restore the filters applied once the user click "done" button. Also we need a mechanism to check if the app is open, using Service perhaps What's your thought Arthur?
Attachment #8548826 - Flags: feedback?(arthur.chen)
Flags: needinfo?(6a68)
Comment on attachment 8548826 [details] [review]
Proposed patch

Note that when triggering an inline activity, it will be executed in another instance, so we should not make the original instance handle the incoming system message.

The root cause is as this comment[1], we need a way for system app telling the difference between the current running instance and the one to be created.

Flags: needinfo?(arthur.chen)
Attachment #8548826 - Flags: feedback?(arthur.chen) → feedback-
The root cause is the same as bug 1119917 as Manuel suggested. Manuel, feel free to take bug 1119917 if you want, thanks!
Last Resolved: 3 years ago
Flags: needinfo?(b.mcb)
Resolution: --- → DUPLICATE
Duplicate of bug: 1119917
I'll clear the nom here and we will monitor the landing in the bug which is DUp'ed, if its low risk enough we can uplift it. Although, I think its edge-casey enough to wontfix it..
blocking-b2g: 2.1? → ---
(In reply to bhavana bajaj [:bajaj] from comment #9)
> I'll clear the nom here and we will monitor the landing in the bug which is
> DUp'ed, if its low risk enough we can uplift it. Although, I think its
> edge-casey enough to wontfix it..

for 2.1
Clearing my ni
Flags: needinfo?(b.mcb)
After bug 1119917 resolved we found that the activity window would be under system dialogs. Reopen this bug to track the issue.
Resolution: DUPLICATE → ---
Hey Arthur, any ideas of how we can solve this issue? The entry sheet is added at the end of the DOM and the z-index is higher that the windows element.

Flags: needinfo?(arthur.chen)
Alive, not sure if this is the same as the bug you are currently working on (the value selector one). Could you help confirm it? Thanks.
Flags: needinfo?(arthur.chen) → needinfo?(alive)
Nope, this one is to support ActivityWindow in SystemDialog.
Flags: needinfo?(alive)
I did a patch but I am afraid it will be dangerous to make system dialog support activity.
The reason is AppWindow has already appTitleBar and appStatusBar but SystemDialog needs to do extra work to cooperate with statusbar, otherwise the activity inside system dialog will have empty statusbar left.
Re-assigning this bug to Alvie. He has a first approach of the patch and more experience in this area. Also I haven't enough time to solve it.

Assignee: b.mcb → alive
Back to this bug again; I found that it's not to support ActivityWindow in SystemDialog but actually in EntrySheet; what's more:
1. SystemDialog of FxA is invoking the EntrySheet from the iframe it's living
2. EntrySheet is displayed on top of the SystemDialog, and it's not managed by HierarchyManager.
3. Since (1) the object reference of the opened EntrySheet instance is not in HierarychyManager's eye.

So what needs to be done:
1. Find a way to open EntrySheet in system app and do that from FxA iframe
2. Make EntrySheet be managed by HierarchyManager
3. Redirect launchactivity event to the active EntrySheet.
Created attachment 8612194 [details] [review]
[gaia] alivedise:bugzilla/1118669/system-dialog-with-activity-window > mozilla-b2g:master
Comment on attachment 8612194 [details] [review]
[gaia] alivedise:bugzilla/1118669/system-dialog-with-activity-window > mozilla-b2g:master

A little complex than I think..

1. Move EntrySheet instantiation From Fxa (in an iframe) to System
2. Manager EntrySheet in HierarchyManager
3. Use BroadcastChannel to request system to open entry sheet
4. Use ServiceBroadcaster to load and request EntrySheet instantiation
5. Display launchactivity event to EntrySheet

Not sure: if we should move EntrySheet.instantiate out from EntrySheet to be a EntrySheetManager...
Attachment #8612194 - Flags: feedback?(etienne)
While working on this I sadly find that we are having problem to support ActivityWindow in SystemDialog.

It's because ActionMenu(Activity Choice) is now a SystemDialog; and if we bypass the launchactivity request to SystemDialogManager, it will pass the event to the ActionMenu which should not catch it.

Still wanna to move ActionMenu into AppWindow...or workaround it in SystemDialogManager if active instance is not a dialog but a menu.
Comment on attachment 8612194 [details] [review]
[gaia] alivedise:bugzilla/1118669/system-dialog-with-activity-window > mozilla-b2g:master

(Note that I'm discovering most of the fxa/entrysheet code so I might not be the best reviewer.)

Anyway, I'm not sure we want to add so much plumbing for such an edge case (the ServiceBroadcaster feels a bit heavy handed for now).

My suggestion for this bug would be to keep it FXA-scoped and do the following:

* add a mozbrowsererror listener to |this.entrySheet.content| when we show the entrySheet
* in the handler, call |this.entrySheet.close| and the already existent |this.showErrorResponse({error: 'OFFLINE'})|
Attachment #8612194 - Flags: feedback?(etienne)

Comment 24

2 months ago
Firefox OS is not being worked on
Last Resolved: 3 years ago2 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.