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

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Browser, defect)

Description

[William Hsu [:whsu]]

+++ 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       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/aedeb9e38bb9
 - 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

Comment 1

[William Hsu [:whsu]]

[Blocking Requested - why for this release]:

A functional defect.

Comment 2

[Wesly Huang (EPM)]

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.

Comment 3

[Wesly Huang (EPM)]

[Blocking Requested - why for this release]:

[Triage] considering 2.0 timing and user impact, nom. to 2.1 instead.

Comment 4

[Manuel Casas Barrado [:mancas]]

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?

Comment 5

[bhavana bajaj [:bajaj]]

Jared, looks like you were helping on https://bugzilla.mozilla.org/show_bug.cgi?id=1082444 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

Comment 6

[Manuel Casas Barrado [:mancas]]

Attachment: 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?

Comment 7

[Arthur Chen [:arthurcc][inactive after 6/30]]

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.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1119917#c6

Comment 8

[Arthur Chen [:arthurcc][inactive after 6/30]]

The root cause is the same as bug 1119917 as Manuel suggested. Manuel, feel free to take bug 1119917 if you want, thanks!

Comment 9

[bhavana bajaj [:bajaj]]

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..

Comment 10

[bhavana bajaj [:bajaj]]

(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

Comment 11

[Manuel Casas Barrado [:mancas]]

Clearing my ni

Comment 12

[Arthur Chen [:arthurcc][inactive after 6/30]]

After bug 1119917 resolved we found that the activity window would be under system dialogs. Reopen this bug to track the issue.

Comment 13

[Manuel Casas Barrado [:mancas]]

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.

Thanks!

Comment 14

[Arthur Chen [:arthurcc][inactive after 6/30]]

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.

Comment 15

[(inactive after 6/18) Alive Kuo [:alive]]

Nope, this one is to support ActivityWindow in SystemDialog.

Comment 16

[(inactive after 6/18) Alive Kuo [: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.

Comment 17

[(inactive after 6/18) Alive Kuo [:alive]]

WIP is here
https://github.com/alivedise/gaia/compare/bugzilla/1118669/system-dialog-with-activity-window?expand=1

Comment 18

[Manuel Casas Barrado [:mancas]]

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.

Thanks

Comment 19

[(inactive after 6/18) Alive Kuo [: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.

Comment 20

[GitHub Autolander Bot]

Attachment: [gaia] alivedise:bugzilla/1118669/system-dialog-with-activity-window > mozilla-b2g:master

Comment 21

[(inactive after 6/18) Alive Kuo [:alive]]

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...

Comment 22

[(inactive after 6/18) Alive Kuo [:alive]]

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 23

[Etienne Segonzac (:etienne)]

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'})|

Comment 24

[BMO Automation]

Firefox OS is not being worked on