Re: Allowing web apps to delay layout/rendering on startup

2015-10-09 Thread zbraniecki 
On Friday, October 9, 2015 at 10:51:54 AM UTC-7, Mounir Lamouri wrote:
> As far as speed feeling goes, they would win to show something as soon
> as possible and handle any post-first paint loading themselves.

That is unfortunately not consistent with my experience. People tend to 
perceive visible progressive as much slower than delayed first-paint in most 
scenarios.

On top of that, it is perceived as a really_bad_ux.

That means that while Gecko is trying to do what you said - paint as soon as 
possible and handle everything later, Firefox OS apps are trying to to exactly 
the opposite - squeeze as much startup JS logic as possible before firstPaint.

Because they cannot control it, it is a condition race between two heuristics 
which includes lots of dirty tricks, unfair punches and other nasty, nasty 
stuff.

What we are trying to get is control over firstPaint for apps that want to 
control when first paint is executed. That would remove the condition race and 
actually free Gecko from the burden of trying to analyze when to start painting.

zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: API request: MutationObserver with querySelector

2015-10-09 Thread Xidorn Quan 
On Sat, Sep 19, 2015 at 5:19 PM, Cameron McCormack  wrote:
> We could probably use the same mechanism that we do for restyling,
> effectively modelling any registered selector observers as an additional
> style sheet rule (that doesn’t have any properties set in it).  All of
> the data we store in the rule cascade so that we can quickly decide
> whether a given element needs to have rule matching run again could be
> re-used.

That probably works for node insertion, but probably doesn't work for
node removal I guess?

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Read only non-privileges access to mozSettings (old navigator.mozHour12 in platform)

2015-10-09 Thread zbraniecki 
On Friday, October 9, 2015 at 6:43:02 AM UTC-7, Ehsan Akhgari wrote:
> On 2015-10-08 8:27 PM, zbranie...@mozilla.com wrote:
> > Currently, any app that needs any of that information, has to get elevated 
> > privileges to let it *set* them, while almost every app that works with UI 
> > will just want to retrieve that.
> 
> As long as you want to do something b2g specific (which from the content 
> of your next email I gather is what you're trying to do now) why not 
> just solve this one issue and keep using mozSettings?

If by one issue you mean "read-only access to selected settings without 
elevated privileges" then I'm totally in.

If you mean "solve the hour12 and let's deal with measure units and weather 
units and first day of the week separately" then I'm afraid that it will each 
time be the same hassle.
Also, even with this one hour12 thing I'm in limbo between "just do this in 
your platform for now" and "standardize it, but design it well which will take 
a lot of time".

So, what is your suggestion?

zb.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: dialog=1 for window.open from web content

2015-10-09 Thread Mike Conley 
One of the arguments to window.open[1] is a “feature string” that is
used to do things like set the size of the newly opened window, to set
whether or not it is resizable, etc.

Gecko currently supports a “dialog” feature that is really only evident
on Windows platforms. This dialog feature essentially hides the
minimize, maximize and restore buttons in the window titlebar. It also
hides the “command” icon (that’s the program icon usually visible in the
top-left corner of a popup window on Windows). Note that it doesn’t
disable the minimizing / maximizing capabilities of the window, it just
hides the buttons. Right-clicking on the titlebar brings up a popup that
allows the user to control the window.

From what I can tell, this is a super old feature, and Gecko is the only
web engine to support it. All other engines just ignore that setting.

Bug 1095236 was filed because when an e10s-enabled Gecko encounters a
window.open with “dialog=1” or “dialog=yes” in the feature string, it
failed to open the window. I didn’t find enough cause for Gecko to keep
supporting the feature when I posted to dev-platform earlier in the
week[2], so I have prepared patches that cause Gecko to ignore the
feature as well for both e10s and non-e10s. This will allow this
window.open calls to work with e10s-enabled Gecko again.

Note that this does not disable the dialog=1 feature when window.open is
called from privileged code from the parent process.

Patches are available in the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1095236

fxcompat has already put up a post:
https://www.fxsitecompat.com/en-US/docs/2015/dialog-option-for-window-open-is-no-longer-supported/

I’ll be landing these patches early next week in mozilla-central unless
I hear a really compelling argument not to.

-Mike

References:

[1]: https://developer.mozilla.org/en-US/docs/Web/API/Window/open
[2]:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/cDpULPod8nQ
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: API request: MutationObserver with querySelector

2015-10-09 Thread smaug 

On 10/09/2015 03:46 AM, zbranie...@mozilla.com wrote:

We're about to start working on another API for the next Firefox OS, this time 
for DOM Intl, that will operate on `data-intl-format`,
`data-intl-value` and `data-intl-options`.

It would be much easier for us to keep l10n and intl separately and 
independently, but in the current model we will have two MutationObservers
reporting everything that happens on document.body just to fish for elements 
with those attributes. Twice.

So we may have to introduce a single mutation observer to that handles that for 
both, which will be a bad design decision but improve performance.

I Reported it a month ago and so far no response. What's my next step to get 
this in our platform?

zb.





Let's try to move this forward in the spec level (we can't really implement 
anything before there is some specification for this).
I added a question to the spec bug.



-Olli
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Allowing web apps to delay layout/rendering on startup

2015-10-09 Thread Mounir Lamouri 
On Fri, 9 Oct 2015, at 16:27, Vivien Nicolas wrote:
> On Thu, Oct 8, 2015 at 6:10 PM, Mounir Lamouri  wrote:
> 
> > Note that Chrome 46 has a way to work around the white screen while a
> > page load using a new property in the Manifest. If a website added to
> > the homescreen on Chrome Android has a background_color information, it
> > will be used while the page loads. After Chrome gets the first paint
> > following a non-empty layout, it will remove that plain colour and
> > switch to whatever the page has ready. It allows websites to be
> > constructed as websites and not rely on that splashscreen feature that
> > might or might not be present (given the UA and the current context) and
> > also keep the principle of quick first paint.
> >
> 
> > Would using a similar system (ie. background_color from the Manifest)
> > help you here?
> >
> 
> 
> I will be happy to use the background_color field in the manifest. It
> will
> likely help web app pinned to the homescreen.
> I also think it will be a great idea to use it to replace the static
> black
> color that is displayed before applications are launched and try to unify
> the experience between installed apps and pinned apps.
> 
> However while I think background_color is useful, the white flash we are
> trying to address here is between the splash screen and the app content
> beeing loaded. I think, but I may be wrong, that we don't want to have a
> 3
> steps startup with:
>  1. Black splashscreen with icon
>  2. plain background_color instead of a white flash
>  3. App content beeing displayed when ready.
> 
> I guess 1. and 2. can be merged.
> 
> Now the issue, if my understanding is correct, Gecko does not have the
> notion of firstpaint after a non-empty layout. Which means even if 1. and
> 2. are merged we can end up in a situation where you have:
>  1./2. background_color with/without icon
>  3. white flash
>  4. App content beeing displayed when ready.

Sorry for misunderstanding.

> So basically what I want to add in bug 1211853 (first attachement) is (a
> very simple) mechanism to not paint until there is something to paint.
> And
> from here provide a mechanism for web app to control when first paint
> happens without enforcing them to be built a specific way.

Did you look into firing the event after there is a non-empty layout or
does that come to the same thing as what your patch is doing? Also, it
seems unfortunate to have applications hacking around the first paint.
As far as speed feeling goes, they would win to show something as soon
as possible and handle any post-first paint loading themselves.

> An other constraints for application with multi-steps startup is to
> display
> something as quick as possible to the user and continue their execution
> after first paint. As of today there is no way (at least in Gecko, dunno
> for Chrome) to know when the UA has painted something on the screen. I
> would like to introduce a (moz)firstpaint event so app authors can
> optimize
> their app to quicly show something on the screen, then wait for the UA to
> paint, and then continue their execution.

I was talking about a firstpaint even to some Chrome folks earlier this
week and I have a TODO to talk with some other folks next week when they
will be back from their holidays. So far, the feedback on this idea was
fairly positive but I need to make sure there isn't something obvious
I'm missing.

-- Mounir
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Read only non-privileges access to mozSettings (old navigator.mozHour12 in platform)

2015-10-09 Thread Ehsan Akhgari 

On 2015-10-08 8:27 PM, zbranie...@mozilla.com wrote:

Currently, any app that needs any of that information, has to get elevated 
privileges to let it *set* them, while almost every app that works with UI will 
just want to retrieve that.


As long as you want to do something b2g specific (which from the content 
of your next email I gather is what you're trying to do now) why not 
just solve this one issue and keep using mozSettings?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Read only non-privileges access to mozSettings (old navigator.mozHour12 in platform)

2015-10-09 Thread Ehsan Akhgari 

On 2015-10-08 8:27 PM, zbranie...@mozilla.com wrote:

Currently, any app that needs any of that information, has to get elevated 
privileges to let it *set* them, while almost every app that works with UI will 
just want to retrieve that.


As long as you want to do something b2g specific (which from the content 
of your next email I gather is what you're trying to do now) why not 
just solve this one issue and keep using mozSettings?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Update: CANCELLED: TCW 10-10-2015 6a - 2p PDT

2015-10-09 Thread Hal Wine 
Happy uninterrupted coding, everyone!


-- Forwarded message --
From: m...@mozilla.com 
Date: Fri, Oct 9, 2015 at 11:15 AM
Subject: Fwd: [Planned] TCW 10-10-2015 6a - 2p PDT
To: all-moco-m...@mozilla.com


The TCW scheduled for tomorrow has been canceled - please have a great weekend.

Thank you,
MOC

If you have any questions or concerns please address them to
m...@mozilla.com or #moc in IRC

Also, visit whistlepig.mozilla.org for all notifications.


-- Forwarded message --
From: 
Date: Mon, Oct 5, 2015 at 12:55 PM
Subject: [Planned] TCW 10-10-2015 6a - 2p PDT
To: all-moco-m...@mozilla.com


Issue Status:  Upcoming
Short Summary: We will have our next tree closing window on 10/10/2015
starting at 6a
to perform the following work:

1206018 Remove netvault puppet module during tree closing window
1209086 migrate treestatus to relengapi/scl3
1210069 ZLB TCW maintenance October 10th
1207701 Cut over generic production DBs from phx1 to scl3
1204114 reboot frontend ZLB nodes
1204964 restart of all buildbot masters

Mozilla IT Maintenance Notification:
--

Issue Status:  Upcoming
Bug IDs:   1204963
Start Date:2015-10-10
Start Time:07:00 PDT
Site:  All
Services:
Impact of Work:During this time we expect no to very brief
disruptions in service.
We do ask that all service owners check their applications after any
Tree Closing Window where
widespread maintenance has occurred to validate.

If you have any questions or concerns please address them to
m...@mozilla.com

Also, visit whistlepig.mozilla.org for all notifications.
--
m...@mozilla.com - m...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Content sniffing: seeking reliable protection of a text HTTP resource

2015-10-09 Thread ian . melven 
On Sunday, October 4, 2015 at 8:50:26 PM UTC-7, Boris Zbarsky wrote:
> On 10/1/15 5:36 PM, Incnis Mrsi wrote:
> > First is "media type (a.k.a. MIME) sniffing", when browser overrides
> > media type/subtype. This is implemented in
> > toolkit/components/mediasniffer/nsMediaSniffer.cpp component (and
> > possibly others, don't know).
> 
> Note that these are generally very conservative in their application. 
> There are very few cases in which we will override a server-provided 
> MIME type for a document load, for example (I think the RSS thing might 
> well be the only case, in fact).
> 
> > There is a proposal
> > https://bugzilla.mozilla.org/show_bug.cgi?id=471020 to make behaviour of
> > Firefox compatible with MS Internet Explorer and
> > https://mimesniff.spec.whatwg.org/#supplied-mime-type-detection-algorithm ,
> > using <> to switch the sniffing off.
> 
> Right, but that proposal needs to actually define what it means to 
> switch the sniffing off.  I don't believe the IE behavior is documented 
> anywhere, unfortunately.

Hi,

Anne has worked to create W3C tests and work towards standardizing the handling 
of nosniff in Fetch in 
https://fetch.spec.whatwg.org/#x-content-type-options-header which might 
possibly make implementation clearer ? 

cheers
ian

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Allowing web apps to delay layout/rendering on startup

2015-10-09 Thread Vivien Nicolas 
On Thu, Oct 8, 2015 at 6:10 PM, Mounir Lamouri  wrote:

> Note that Chrome 46 has a way to work around the white screen while a
> page load using a new property in the Manifest. If a website added to
> the homescreen on Chrome Android has a background_color information, it
> will be used while the page loads. After Chrome gets the first paint
> following a non-empty layout, it will remove that plain colour and
> switch to whatever the page has ready. It allows websites to be
> constructed as websites and not rely on that splashscreen feature that
> might or might not be present (given the UA and the current context) and
> also keep the principle of quick first paint.
>

> Would using a similar system (ie. background_color from the Manifest)
> help you here?
>


I will be happy to use the background_color field in the manifest. It will
likely help web app pinned to the homescreen.
I also think it will be a great idea to use it to replace the static black
color that is displayed before applications are launched and try to unify
the experience between installed apps and pinned apps.

However while I think background_color is useful, the white flash we are
trying to address here is between the splash screen and the app content
beeing loaded. I think, but I may be wrong, that we don't want to have a 3
steps startup with:
 1. Black splashscreen with icon
 2. plain background_color instead of a white flash
 3. App content beeing displayed when ready.

I guess 1. and 2. can be merged.

Now the issue, if my understanding is correct, Gecko does not have the
notion of firstpaint after a non-empty layout. Which means even if 1. and
2. are merged we can end up in a situation where you have:
 1./2. background_color with/without icon
 3. white flash
 4. App content beeing displayed when ready.

So basically what I want to add in bug 1211853 (first attachement) is (a
very simple) mechanism to not paint until there is something to paint. And
from here provide a mechanism for web app to control when first paint
happens without enforcing them to be built a specific way.

As James mentioned, background_color may also be tricky to used for
applications with dynamic first page. For instance if you want to have a
setup page with a different background color than the rest of your
application. That said I still believe it can be useful for the vast
majority of apps.

An other constraints for application with multi-steps startup is to display
something as quick as possible to the user and continue their execution
after first paint. As of today there is no way (at least in Gecko, dunno
for Chrome) to know when the UA has painted something on the screen. I
would like to introduce a (moz)firstpaint event so app authors can optimize
their app to quicly show something on the screen, then wait for the UA to
paint, and then continue their execution.

Vivien.


>
> -- Mounir
>
> On Wed, 7 Oct 2015, at 14:17, vnico...@mozilla.com wrote:
> > I also forgot to say that the proposed solution does not help for cases
> > like bug 1199674 afaict.
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform