MOZ_CRASH-invoked crashes are now annotated

[Michael Layzell]

Bugs 1183355 and 1209958 have now landed on inbound, which means that
crashes caused by MOZ_CRASH in release builds will now be annotated, and
the annotation reasons should be visible on crash-stats. Currently the
crash will be annotated with any string literals passed to the MOZ_CRASH
macro, so MOZ_CRASH("Oh no!") will be annotated with MozCrashReason =
"MOZ_CRASH(Oh no!)".

MOZ_RELEASE_ASSERT isn't annotated yet, that will be coming with bug
1211979.
___
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

[Mounir Lamouri]

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?

-- 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

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

[James Burke]

On Thu, Oct 8, 2015 at 9:10 AM, 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 am unsure of the needs related to bug 1199674, but on the manifest
background color: if it is a color that is set in the manifest, I find
that marginally more useful than a flash of white before painting.

What if the UI has different start colors? It would be a noticeable
abrupt transition. For email, if no accounts configured, the
background is a light gray. If accounts are configured, the header is
an orange but the bulk of the content area uses a white color.

To me, the use of a solid color, particularly if white, just looks
like the typical browser new tab white loading screen. I am purposely
trying to avoid that in email. I liked that Firefox OS uses the icon
as part of the app launch transition, it felt different than a single
color paint. Go from startup animation with the app icon to meaningful
content.

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

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

[zbraniecki]

In a couple threads we've been debating back and forth about what we currently 
have as navigator.mozHour12 in Firefox OS.

It's a tri-value setting (undefined, true, false) that we take from mozSettings 
to adjust our Clock to use user chosen setting.

For a while, I've been asking to get it in the platform and the response was 
that we should aim to standardize it.

The challenge with standardizing it is that it is just one of many values that 
we will want to have. We can standardize just this single variable, but soon, 
we will have to standardize another, and then another and so on.

When I brought it up asking to design the API to flexible for future values, it 
instantly scaled up complexity for some participants.

So, I spent some time planning and thinking about it, and I came up with a set 
of user-defined variables that we should expose to web authors, and a proposal 
for an API to do so.

The variables:

 ! hour 12/24 clock (undefined, true, false)
 ! first day of the week (integer 0-6)
 ! weather unit (celsius, fahrenheit, kelvin)
 ! distance units (metric, imperial)
 - weekendStarts (integer 0-6)
 - weekendEnds (integer 0-6)
 - show seconds (undefined, true, false)
 - calendar (string - gregorian, buddhist, coptic etc.)
 - currentTimezone
 - currency
 - sorting settings

And those are only l10n/intl related ones. I can imagine that other areas might 
have similar needs:

 - accessibility (high-contrast, reverse colors etc.)
 - parental controls (hide explicit content)
 - notifications (lots of opportunity here)
 - sounds settings (mute, vibrate, level for different sound types)

and even some things that we already expose in various ways that would really 
fit as part of that API:

 - network status (online, offline, download speed, upload speed)

Not all of them are needed now, I marked the ones we should expose now with 
"!", but those are the kind of values that we may want at some point to:
 - allow users to set in Settings
 - have some automatic value for that may be dynamically computed (like, 
default hour12 depends on language settings)
 - allow apps to retrieve

I understand that we want to start small, but I'm confident that we should for 
the 4 settings market by me with "!" start looking for a solution.

And I believe that it shouldn't be that we expose each variable separately, on 
navigator. I believe that we should plan it as a counterpart to mozSettings API 
because it is, after all, read-only view of user settings.

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.

Can we get something for our platform for now so that we can increase security 
and move forward with allowing ourselves and third-party devs create good UX in 
Firefox OS, and then merge this feature with our work to standardize 
mozSettings?

Thanks,
zb.
___
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)

[zbraniecki]

I promised a proposal:

navigator.mozSettings.get('locale.hour12').then(value => {
  console.log('value for locale.hour12 is: ' + value);
});

This would be asynchronous, and only available for a small set of variables 
(whitelisted).

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

Re: API request: MutationObserver with querySelector

[zbraniecki]

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.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform