On Mon, Jul 1, 2013 at 9:31 PM, Vivien <[email protected]> wrote: > On 01/07/2013 10:55, Tim Chien wrote: >> Vivien have not answer my needinfo for almost a month. > > > Tim there was this thread on dev-webapps about the 'icons' part in the > manifest. Have you seen it? > > https://groups.google.com/forum/#!topic/mozilla.dev.webapps/WBWsaP87IRk >
Yes I have, but I thought the discussion is specifically about icons and not splashes. On Mon, Jul 1, 2013 at 9:48 PM, Mounir Lamouri <[email protected]> wrote: > Hi, > > First of all, it would be great if that kind of discussions could happen > in dev-webapi or dev-webapps. I know that Gaia is doing its own manifest > parsing but the manifest spec is being worked on by the Web API team and > some of us (Marcos and I mostly) have opinions on how that kind of stuff > should work. We actually already had this discussion with developers and > have some ideas. (Kudos for CCing me though, it helped me noticed the > thread.) > Will do next time! > Second of all, Marcos and I really dislike the current v1-train feature > (biggest icon being the splash screen) and we would like this to be > removed. I had that discussion with Vivien a couple of weeks ago and he > seemed to agree that removing the feature before we ship would be a good > idea. > They are on master, not v1-train, and the patch for removal is already there; we just need a r+ for that https://bugzilla.mozilla.org/show_bug.cgi?id=873431 > What I would like to see here is to start with removing the hack that > makes Gaia pick the splash screen from the icons list. This hack is > application facing and we will see applications actually using it to > have big icons being used as splash screens. The problem is that that > hack would only work for a specific set of devices (same screen size) > and given that it will be application facing, it would need to be added > to the specifications. I think those are good reasons to not ship this. Yes! and the next release on master branch is months away ... > After that, a bit off-topic but related to the HD effort, I think it > would be great if Gaia could use the new icons proposal that Marcos and > I did [1]. > Noted. I have not follow the discussion all the way to the end. I stopped at the question about compatibility between old manifests; will join the discussion. > 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 Again, my personal preference is to go for (3) with |splashHTML| > > It would be great if we could implement a sane step 1: we define a > system-wide splash screen. It can be implemented in various ways: using > a generic icon, background and text; using the app icon but generic > background and text; etc.. An implementation like that should give us a > fast splash screen that would work with various devices. > This can be served as a sane default I guess. > 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. > 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) > 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. > 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". > 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. > Therefore, I think that the system splash screen should not be used as a > replacement for an in-app slash screen and we should actually keep in > mind that applications might want there own splash screen. Take the > example of a game loading assets like textures, musics, etc. The game > will handle that in its own loading page. The music app might be another > example: it should handle its own loading state. Agree. > 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. -- Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox OS, Mozilla Corp. (Taiwan) _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
