618912 - Prototype a xul-less ui for fennec on android

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[(dormant account)]

Setting our chrome to a xul "hello world" takes 2s to start up vs 1s for an html-based one. 
We should build prototype where the main window is implemented in html, with android menu key providing access to other functionality(which can remain as xul/xbl).
Benefits are faster startup and reduced resource usage due to not having to load xul infrastructure.

Comment 1

[Brendan Eich [:brendan]]

Not here to rain on your parade. Wanted to share a couple of thoughts:

There's already the "chromeless" Mozilla Labs experiment using HTML/CSS/JS to make an embeddable browser:

http://mozillalabs.com/chromeless/2010/10/21/chromeless-build-your-own-browser-ui-using-html-css-js/

But "hello world" is not a good testcase. A more realistic XUL input would erect real App UI, not all of which can be done with pure HTML and CSS. Writing layout engines in JS sucks and will not compete.

Long-term we want all the XUL magic that makes sense in the Web platform, but:

(a) that's long-term, we're nowhere near "there" yet;

(b) the "all that makes sense" proviso matters: some things a mobile or desktop app needs won't fit into the Web standards, so long as there's a difference between OS-hosted apps and web apps or pages.

(I'm gonna go out on a  limb and predict there will always be the (b) gap, but it'll matter less over time. It will still matter, for trust reasons that can't be solved with technology alone.)

/be

Comment 2

[(dormant account)]

(In reply to comment #1)
> Not here to rain on your parade. Wanted to share a couple of thoughts:
> 
> There's already the "chromeless" Mozilla Labs experiment using HTML/CSS/JS to
> make an embeddable browser:
> 
> http://mozillalabs.com/chromeless/2010/10/21/chromeless-build-your-own-browser-ui-using-html-css-js/

Yeah I know, I spoke to Mauricio about it at allhands.

> 
> But "hello world" is not a good testcase. A more realistic XUL input would
> erect real App UI, not all of which can be done with pure HTML and CSS. Writing
> layout engines in JS sucks and will not compete.
> 
> Long-term we want all the XUL magic that makes sense in the Web platform, but:
> 
> (a) that's long-term, we're nowhere near "there" yet;
> 
> (b) the "all that makes sense" proviso matters: some things a mobile or desktop
> app needs won't fit into the Web standards, so long as there's a difference
> between OS-hosted apps and web apps or pages.
> 
> (I'm gonna go out on a  limb and predict there will always be the (b) gap, but
> it'll matter less over time. It will still matter, for trust reasons that can't
> be solved with technology alone.)

In this case I'm talking about fennec on android where there literally doesn't have to be any browser ui(until one pushes the menu key). I think it's a perfect candidate for experimentation. 

Waiting for a "long-term" future doesn't accomplish anything. I think this is doable in the nearterm on mobile, on android.

Comment 3

[Stuart Parmenter]

Building a UI in just HTML is a huge pain in the ass unless you have a real box/flex/spring model.  Marking all your divs style="display: -moz-box" is a huge pain as well.  I started down a HTML path when I was rewriting Fennec a year or two ago, but ran in to problem after problem.  CSS needs a bunch of new ways of specifying layout that just aren't there yet.

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

I also worry about the affect on add-ons and extensibility when using HTML for our markup.

I am currently trying to remove as much markup from browser.xul as possible and delay load as much JS as we can, avoiding <script> tags. I think I can get to delay loading nearly all of our JS. I landed some today in bug 622423. I have some more work to do there. The Ts result was small, ~100ms savings.

Comment 5

[Brendan Eich [:brendan]]

(In reply to comment #2)
> Yeah I know, I spoke to Mauricio about it at allhands.

(Marcio)

> Waiting for a "long-term" future doesn't accomplish anything. I think this is
> doable in the nearterm on mobile, on android.

I never said anything about waiting :-/.

Indeed I think you misunderstood my whole speculative point about web app vs. native app parity, viz different trust models, but it's not important.

/be

Comment 6

[Brendan Eich [:brendan]]

Apple did blaze trails here, extending CSS (still doing that, not all of it yet in front of the CSS WG). We can play too, and should (and we have, where there's a spec). It's a long road we're on, just set your expectations accordingly. Try to press the pedal on the right -- I'll help.

/be

Comment 7

[/\/\arcio Galli]

(In reply to comment #3)
> Building a UI in just HTML is a huge pain in the ass unless you have a real
> box/flex/spring model.  Marking all your divs style="display: -moz-box" is a
> huge pain as well.  I started down a HTML path when I was rewriting Fennec a
> year or two ago, but ran in to problem after problem.  CSS needs a bunch of new
> ways of specifying layout that just aren't there yet.

@Pav

I feel the Fennec UI is very minimal. I wonder if the more we drive towards minimal, if is it real the "pain" to develop. 

But assuming it is, and we do not have a good box/flex model in HTML. Then I wonder your opinion if you think it would work if we get rid of the whole UI, and, let's say, we make browser commands = API. A service, like FUEL stuff. Would it then work? Aside from the UX implications = not having an UI. 

@Taras,

there is another thing maybe here for your initial case. I feel that if we put a XUL:browser in there, and we initialize everything, it would continue to use extra time. Perhaps? File IO/preferences/session stuff, and many other "gBrowser" things. One thing in Chromeless is that the experimentation prototype is not bringing up a bunch of things up.

Comment 8

[(dormant account)]

Attachment: hello world xul

Comment 9

[(dormant account)]

Attachment: hello world html

My best possible startup(ie warm) is 1second with above html chrome.
hello-world xul chrome takes about 150-200ms longer

The most shocking part is that loading a basic chrome uses about 25mb of ram(according to android task manager). Whereas full fennec chrome weighs in at 55mb. Given that basic chromes are also loading a webpage via IPC, 50% overhead of pretty chrome seems excessive.

Comment 10

[Brendan Eich [:brendan]]

What's behind all the chrome overhead reported in comment 9?

Comment 7 suggests using an "API", that is, writing flex-box layout or whatever in JS. This is the Turing tarpit and it is sure to lose to native code, even with our fancy JITs. We ought to have flex-box in CSS, and other stuff. Keep writing those letters to your CSS representatives ;-).

/be

Comment 11

[Benjamin Stover (:stechz)]

Actually, perhaps CSS3's calc and layout grid is a superset of flex functionality anyway. I'm not sure JS is needed for calculating any dimensions. In fact, Fennec has JS size calculation code that could be replaced with calc right now.

Maybe a flex master (a person, not an exercise machine) could chime in with a case where CSS3 isn't good enough already.

Comment 12

[Benjamin Stover (:stechz)]

Hm, I don't think I realized that the layout-grid stuff in the CSS3 spec isn't our proposal so I'm assuming there's no implementation of it in Firefox yet (it looks really neat though; there are very interesting possibilities). Still, for Fennec we might be able to get by on calc.

Comment 13

[Brendan Eich [:brendan]]

CSS3 is giant pie-in-the-sky. Meanwhile back on earth we have flex-box built right in. But it has bugs when used with HTML that it does not have with XUL, I'm told (due to original implementation being only for XUL, and XUL and HTML content models being quite different).

Whatever we do will take some work, but my point was that it ought to be C++ not JS. The nearest to being done still looks like flexible box.

/be

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Also worth noting that the current flexbox layout implementation is rubbish, and slow. Doing a better one is near the top of our priority list.

Comment 15

[(dormant account)]

Attachment: allow remote iframes

Need this patch for html chrome sample above to work.

Comment 16

[/\/\arcio Galli]

@be @all 

Comment 10 refers to comment 7. Wanted to add a bit more to my note when I mentioned API. I was not trying to say API = flexbox in JS. I was referring to the case of browser commands API: 

* https://gist.github.com/709681
* https://wiki.mozilla.org/Labs/Jetpack/Modules

Pointing out the possibility that if main browser commands = API would change a bit the discussion ( or at least points in  comment 3 ). It would sort of enable a reset in the UI discussion. Developers could explore many ways to do UI for browsers ( Webgl, HTML, etc ) and this could continue to gather requirements and priorization to key areas -- as it was mentioned flexbox in CSS for HTML is a good one.

Comment 17

[Doug Turner (:dougt)]

marking fixed.  this is basically what we are doing.