Bug 922641 (separate-modals)

[Meta] Move modal dialogs out of index.html page for apps

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
5 years ago
6 months ago

People

(Reporter: vingtetun, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

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.
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?
Uh....this is in-app navigation's meta bug, right?
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.
(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.
Alias: separate-modals

Comment 5

6 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.