Hi, Last Thursday, Vivien, Marcos and I had a meeting to discuss a few issues around WebAPI and Gaia and the splash screen was one of them.
Vivien gave us very interesting numbers and facts. It seems that we only show the splash screen when the application has started. Which means that Gecko starting up and the process being created doesn't have any splash screen. This part is actually pretty quick and if I remember correctly, Vivien told us that there is 200-300ms between the user clicking on the app and the app starting to load. Based on that, we moved the discussion to whether or not the splash screen should be handled by the content or the system. It seems that given that the content gets loaded pretty quickly, we could easily asks the application to handle its own splash screen. This would remove all the problems we currently have regarding how the splash screen should be defined. We reached an agreement to experiment removing the splash screen from the system and make it handled by the applications in Gaia. Vivien said that it should be doable pretty quickly. Marcos and I are looking forward to hear the results of that experiment. Thanks, -- Mounir On 02/07/13 06:33, Tim Chien wrote: > The |splashHTML| approach suggested by :roc is written here: > https://groups.google.com/d/msg/mozilla.dev.gaia/BFRPwibL64E/XWiYss120CIJ > Sorry for not put up the link earlier. > > Basically the splash.html will get loaded on install time, with > screenshot taken, and never being loaded again until the next app > update. > > Please re-estimate your preference based on the idea here. Thanks. > > On Tue, Jul 2, 2013 at 6:24 PM, Mounir Lamouri <[email protected]> wrote: >> 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 > > > _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
