922641 - (separate-modals) [Meta] Move modal dialogs out of index.html page for apps

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia, defect)

Description

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Many pages have a one or multiple modal dialogs that happens for different actions.
 There is a lot of inconsistencies between the apps, sometimes it comes from the top, sometimes the bottom, sometimes it just appears as if).

Moving them out of the index.html page would let up open them with something like window.open and apply a consistent system wide transition to them. It will also move some html/css/js out of the currently omnipotent index.html file of apps.

Defining this bug as a meta to track the work on a per-app basis.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

I'm not sure we want to use window.open for this, but maybe web components/Brick, or some type of browser syntactic sugar to allow desktop browsers to create an in-document popup-iframe oriented on a click point/element?  window.open seems less aligned with our general 'webby' goals; if anything, web browsers hate pop-ups.

Specifically, I know the plan for Haida is to do more page transition-like stuff where apps currently do card juggling themselves.  And that does seem webby because then we are maintaining state in the URL managed by the browser/system, and that is good.

At least in the e-mail app, the modal dialogs we use are for some combination of:

1) UI actions that a desktop web UI would not use a modal dialog for.  For example, we use the shared-ish value_selector.js to create what currently amounts to a more stylable <select> box to pick the target folder for message moves.  A fancier version of that mechanism in the future might include a filtering auto-complete textbox.

2) Slightly fancier window.confirm/window.alert purposes.  FxOS visual design guidelines require more than they can provide: 2 different strings, specific colors on buttons based on context, custom strings for buttoms.  Also, Bug 818047 has not been fixed in the system app so window.alert/confirm don't work with the building blocks CSS correctly.


Elaborating on alternatives, having something like window.openInDocPopupIframe(url, clickEvent, callback) or for pre-fetching purposes, something declarative like <popup-iframe> seems like it could work well in general.  In the desktop app, we'd use the mechanism to pop-up the folder-picker UI.  In the Gaia/mobile app, we trigger a window.open to the new card.

And the other possibility is to hide the stuff that varies with web components/Brick.  For Gaia/mobile we have it do window.open, for desktop (and tablet?), we have it display the pop-up within the document.


In general this seems like something we should discuss more on dev-gaia or a standards list first?

Comment 2

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

Uh....this is in-app navigation's meta bug, right?

Comment 3

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

So first I should have splitted this bug into 2 separate bugs. One for moving modals/dialogs code out of the omnipotent index.html file and one other to launch it using a platform mechanism in order to benefit from the OS UX across versions.

So let's consider this bug like 'Move modal dialogs code out of index.html for applications' and do whatever mechanism you want to load it for now. Does it sounds good?

Then I opened bug 923453 and copy-paste your comment with mine inline.

Comment 4

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Alive Kuo [:alive] from comment #2)
> Uh....this is in-app navigation's meta bug, right?

Well I plan to split that into different bugs since the work will expand into multiple release and that will make it easier to track it down this way.

But basically here is what I have in mind as a plan to open multiple bugs:
 1.3:
  - Move all modal dialogs inside a separate page (all css/js/html) and open them as a in-document iframe.
  - Move all inline activities panels inside a separate page (all css/js/html) and open them as a in-document iframe

1.4: 
  - Move all panels inside a separate page (all css/js/html) and open them as a in-document iframe.
  - Load inline activities inside their own separate mozbrowser iframe (as today) but without going through index.html.
  - Load all modal dialogs with window.open or similar.

1.5:
  - Move all panels to window.open or similar.

Comment 5

[BMO Automation]

Firefox OS is not being worked on