923453 - [Gaia] Use window.open or similar mechanism to open dialogs

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia, defect)

Description

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

This bug is the result of splitting bug 922641 into 2. Bug 922641 is to move modal dialogs html/css/js out of index.html while this one is to use a platform mechanism to delegate the opening/closing of those to the system app in order to offer a consistent UX across the OS.

My first though is to use window.open since it is already a standard and allow many options.

Comment 1

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

This is an answer to the comment that has made me split the original bug into 2 parts.
---------


(In reply to Andrew Sutherland (:asuth) from comment #1)
> 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?  

The popup-iframe should really not be in-document. Having a separate context, and delegating the opening/closing animations to the system app will result into a much more consistent UX all across the place and between versions, both for our apps (the transitions are currently in flux in many apps) and for third party developers. 

Now if the stuff that wraps this logic is a web component or not, or if the modal.html page contains a web component I don't mind :)

> window.open seems less aligned with our general 'webby'
> goals; if anything, web browsers hate pop-ups.

window.open('foo.html', '_blank') is equal to <a href="foo.html" target="_blank"> or <form target="_blank"> and this is used heavily across the web (maybe not the form stuff). But at least there is a declarative and imperative way of achieving the same thing. There is even some parameters to move the window to a specific position if we decide to support that in the future.

There is also window.showModalDialog. But this one as the side effect of beeing modal as its name says (it is not yet implemented as well).

In terms of UX those dialogs should open on top of the current window and will benefit from the same trusted event policy than a regular web browser. So if one application is annoying it will be identied instantly and you can just stop using it, or even uninstall it.


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


Maybe I should not have use the term 'modal' in my bug description. Passing dialog=1 to the window.open parameter should be enough, while modal is a separate thing.


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

Sadly window.confirm/alert have the issues of not beeing modal and not very configurable. I spoke to Jonas a long time ago about that and from what I remember he was having doubt about having a standardizable API for that. But I will hope that it was because I explained myself wrongly and needinfo? him to double check.

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

Yeah, hiding the logic somewhere sounds good to me as long the popup lives into a separate document managed by the system app.
 
> In general this seems like something we should discuss more on dev-gaia or a
> standards list first?

In all cases moving modals out of the core apps code won't hurt and will have side benefits. And a first step would be to open this popup as a separate iframe inside the document. If we can achieve this for 1.3 this is already good.

For dev-gaia I already sent a few threads about splitting page logic, I have an opinion about how to make it happens, others have different opinions, but in all cases and in order to have a consistent UX that can be changed between versions without having to update all apps (locals and the one from third party) it seems clear that we need to delegate that to the system app. And having separate pages is a common part for most solution you can imagine, so let's say this bug is about that for now and window.open vs something else would come later as a separate bug.

Then about standards if we use window.open in the future it seems like this is a old fashioned stuff that has been standardized for a while :)

Comment 2

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

To briefly summarize my previous post here (and since my original post was long :)

- I completely agree that for UX reasons it makes sense in gaia for the system app to be in charge of the transitions and display of the modal stuff.

- I agree that window.open is a standard, but on desktop you wouldn't use window.open for the same things you are proposing to use it for on mobile.  Just as the <select> UI on FxOS is modal, but on desktop is just a popup, most UI affordances for data input will be popups instead of new pages/contexts.  <select> provides a clean abstraction layer, but people frequently have to resort to approximating its UI for more complicated cases.  So we need a standard that allows things to be more consistent across both worlds, even though we know exactly how we want it implemented on Firefox OS.  Adding an additional parameter to window.open that visually presents a popup panel-type thing seems nice/good.  (And I do think letting that popup UI run in its own clean context is a good software engineering thing in general.)

I look forward to Jonas's feedback!

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I definitely think it would be good if we could let webpages open an "overlay" on top of the current window. I think something like dialog=1 would work well for that. Obviously this is something that we should try to get standardized, but I think that would be easier to do once we have a bit more implementation experience.

Another option here is to implement <dialog> and put in <iframe> inside that. That should work in many cases, but wouldn't work for something like facebook login, since the facebook page will need to be able to protect itself against clickjacking by making sure that it is a toplevel window.

Comment 4

[BMO Automation]

Firefox OS is not being worked on