On 02/07/13 09:41, Tim Chien wrote:
Regarding the splash screen feature, the Web API team opinion so far (at
least as far as Marcos and I are concerned) is that we should not have
any application facing customisation for the moment.
There are basically three sane ways to handle splash screens:
1. using a system default splash screen for every applications;
2. same as 1. but we also allow applications to customise it with a
specific background colour or icon;
3. we allow the applications to use markup to specify the splash screen.
Those three ways should be seen as steps. If step 1 isn't enough, we
should go to 2 then 3. "Not enough" is defined by third-party developers
requests. Currently, Firefox OS is at step 0: there is a system that
looks like step 1 but complex and known to be broken.
Yeah, incidentally, that's the info from BD too, see
https://bugzilla.mozilla.org/show_bug.cgi?id=886484
Is BD Business Development?
When I say we need feedback from third-party developers I did not meant
that we need feedback from *one* third party developer that remains
un-named, with which we can't have a technical discussion and with which
we have a business relationship so we would be more inclined to realise
any of its wishes.
The second point is the most important here: we can't consider this a
genuine feedback given that the developer isn't in direct contact with
us (developers) so we don't know how much the problem and the solution
are actually related.
Again, my personal preference is to go for (3) with |splashHTML|
Could you elaborate on that? Some arguments in favour of this solution
without even trying the others would be interesting to hear.
We could go to step 2 later if developers want to be able to customise
the default splash screen being shown like being able to define the
background or the icon but this is something tricky because the icon
would have to be defined in various sizes and having an image as a
background would be very hard to do right.
IMHO we can never do this right. Ever. We are not Apple who control
every aspects of the OS, including screen sizes.
We can easily allow the developer to provide a set of icons to use in
the splash screen and set a non-image background (gradient or plain
colours for example).
The last step is also complex because the markup would be likely opened
by the system/homescreen/whatever app to increase the startup speed but
then scripts must be disabled otherwise it would lead to funky security
holes. The simple idea of opening an untrusted page in a trusted context
sounds scary to me.
This is untrue. The splash screen will be loaded with<iframe
mozbrowser remote>, and it would offer the same security as any app.
(Unfortunately that would make screenshot-taking expensive too because
we would need to fork a new process specifically for this short-lived
iframe)
What is the point of the splash screen if we still need to create a new
process and start Gecko in it in order to show the splash screen? At
that point, we could as well just show the app.
Tim's proposal to take a screenshot of the HTML page isn't satisfactory
either because if an application is able to define its own splash screen
in HTML it would expect animations to work, whether CSS animations,
animated images or anything else.
I don't want to steal credit from :roc :) It was not my proposal.
Yeah, I guess the app developers would have to asume that |splashHTML|
will be loaded with
- script disabled
- probably network connection disabled too for packaged app
- CSS/GIF animation "disabled"
It's not great but it's the best we could offer, IMO.
What's the difference between that and a standard splash screen? Do we
know for sure that developers would prefer this solution over a standard
splash screen? Very likely, developers will come to us and complain that
they can't have animations in the splash screen (this isn't uncommon to
have).
Forcing a plain image might not solve the situation that would lead us
to step 3. This is actually why we want this to be done steps by steps
so the feedback we get would allow us to know what are the constraints
and requirements.
I am very thankful for your breakdown approach. However we do need to
have the v1.2 schedule in mind when to make decisions based on
"collecting feedbacks".
It is not clear to me why v1.2 schedule forces us to go with a less good
solution and forces to not gather feedback based on one implementation
in order to know how to improve it.
Finally, I would like to underline that the system splash screen should
only be used between the user doing an action requiring to start an
application and the application being started. The problem is how do we
define that the application has started. The 'load' event _might_ be a
solution but it is also known to take a long time to fire sometimes. The
splash screen might be hidden when Gecko is loaded and the page starts
being loaded. We should also simply have a timeout (hide the slash
screen after X ms). A mix of multiple solutions could work too. This
said, we might expect the splash screen to show up for a short time for
packaged applications and longer for hosted applications with no offline
support.
I overlooked this part because the problem will be there whenever
approach we choice. Though we kind of workaround this by putting the
icon splash/screenshot under the app content as the background image
of the iframe.
I won't say it's free of side effect though.
Which behaviour the current splash screen has regarding hiding?
Both screenshot (v1-train) and icon splash (master) is being put under
the iframe as it's background, so they don't block the user from
seeing the actual screen.
For master, the icon splash will go away when the mozbrowserloadend.
For v1-train, the screenshot will go away *after* mozbrowserloadend
fires and the getScreenshot() asnyc call come back.
Does that mean that the splash screen only appears when the process has
been created and Gecko started? Basically, when the page starts loading?
Why do we need a splash screen for a that point?
--
Mounir
