Intent to prototype: unprefixed appearance property

[Cameron McCormack]

Summary:

The appearance property allows authors to specify that a widget element (such 
as a form control element) is to be rendered as a regular element without its 
usual themed appearance.  For example, `appearance: none` on a  
prevents the element from being rendered with its usual (currently platform 
specific) push button appearance, and instead it is rendered using only CSS 
rules from the UA style sheet and those that the author supplies.

There are a number of differences from what the current prefixed 
-moz-appearance property supports:

* There is a new auto value, which means "render the element with its usual 
appearance".  The UA style sheet will be updated to specify `appearance: auto` 
for all widget elements.

* Most of the values supported by -moz-appearance are not supported by 
appearance.

* The remaining values (apart from none and auto) that are still supported have 
limited effect: the button value has no effect on certain widgets (instead of 
having an effect on any element); and the checkbox, listbox, menulist, meter, 
progress-bar, radio, searchfield, and textarea values all behave like auto.  
The need to keep these values around with limited effect is a result of Simon 
Pieters' Web compatibility research, and allows style sheets like the following 
to keep working, without needing to support styling all elements with a given 
widget appearance:

  input[type=checkbox] { -moz-appearance: none; }
  input[type=checkbox].native { -moz-appearance: checkbox; } /* turn native 
checkbox appearance back on */

Once all engines support the new auto value, authors will be recommended to use 
that instead of specific values like checkbox.

Telemetry that has been added for -moz-appearance indicates that the new 
limited effects of these values, and the removal of the others, will be safe.

-moz-appearance and -webkit-appearance will be pure aliases of appearance.

Because we currently use -moz-appearance in UA style sheets (and various chrome 
style sheets for XUL elements and other front end features) to define the 
widget style to use for particular elements, we'll need a new mechanism to 
specify this.  This will be a new chrome/UA-only property 
-moz-default-appearance, which accepts the same extended set of values that 
-moz-appearance currently does.  As a couple of examples, the rule for  
elements in forms.css will change from

  input { -moz-appearance: textfield; ... }

to

  input { appearance: auto; -moz-default-appearance: textfield; ... }

and the rule for the places sidebar in browser/themes/osx/places/organizer.css 
will change from

  #placesList { -moz-appearance: -moz-mac-source-list; ... }

to

  #placesList { appearance: auto; -moz-default-appearance: 
-moz-mac-source-list; ... }


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1620467

Standard: https://drafts.csswg.org/css-ui-4/#styling-widgets

Platform coverage: all

Preference: none; it's difficult to make a large change to an existing property 
like this and have all of the consequent changes be pref controllable

DevTools bug: none

Other browsers:

* Chrome: Changes landed ~3 months ago, targeting M84: 
https://bugs.chromium.org/p/chromium/issues/detail?id=963551
* Safari: https://bugs.webkit.org/show_bug.cgi?id=143842 is filed and 
internally tracked, and I am told "we have no immediate plan to do it, but it 
seems likely to be something we will do eventually".

web-platform-tests: 
https://wpt.fyi/results/css/css-ui?label=master=experimental=appearance

Secure contexts: Not restricted to secure contexts. This is not a feature that 
authors will be looking for and which we could hold back from insecure contexts 
to convince them to change, and Chrome also does not plan to restrict this to 
secure contexts.

Is this feature enabled by default in sandboxed iframes? yes
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

More volunteers needed for nightly crash triage rotation

[Gabriele Svelto]

[cross posting to firefox-dev and stability]

 Hello all,
the crash triage team needs your help in keeping Firefox stable! The
role of the triagers is to have a look at the crashes for a certain
version of nightly a few days after it has been released and file bugs
for crashes that haven't been identified yet. This is usually done to
quickly identify regressions but it often also involves looking at
low-volume crashes that flew under the radar or platform-specific issue
that only appear with specific configurations.

Triage is usually done on a daily basis: every triager looks at a
certain day worth of crashes, for example on Monday morning I analyze
the crashes for the previous Friday's nightly build.

Currently we need help for the following days:

* Monday nightlies (to be triaged on Wednesday or Thursday)
* Thursday nightlies (to be triaged on Friday or Monday)
* Saturday nightlies (to be triaged on Monday or Tuesday)

The days in which the triage will happen is a suggestion, if you have
time another day it's fine given it's at least 24-48h after the build
was released.

In case you're interested please contact me and I'll be happy to walk
you through the process and also mentor you for your first sessions if
you're unfamiliar with crash analysis.

For further information also please have a look at our wiki page, fairly
up-to-date docs are linked from there:

https://wiki.mozilla.org/NightlyCrashTriage

 Gabriele



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changes to string literals

[Simon Giesecke]

Hi,

I was asked that yesterday already, but I think it didn't go to the list. I
didn't have that documentation in my mind, but I will definitely give it a
look now! Maybe I'll ask sledru regarding plans for moving the docs to the
tree.

BTW: The plan now is to remove the NS_LITERAL_STRING and NS_LITERAL_CSTRING
macros tomorrow, and I will take care to adapt any new uses that land until
then.

Best wishes
Simon

On Thu, Jul 2, 2020 at 9:14 AM Frederik Braun  wrote:

> Thank you Simon, that looks way more ergonomic!
> A bummer, I'll have to modify my in-flight patches though :-)
>
> Do you intend to update existing documentation at
> <
> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Guide/Internal_strings
> >
> (or move it to firefox source docs)?
>
>
>
> Am 01.07.20 um 16:53 schrieb Simon Giesecke:
> > Hi,
> >
> > until Bug 1648010, there were some macros widely used for the handling of
> > string literals, i.e. NS_LITERAL_STRING, NS_LITERAL_CSTRING,
> > NS_NAMED_LITERAL_STRING, NS_NAMED_LITERAL_CSTRING. These macros have
> resp.
> > will have been removed once all patches for that bug landed.
> >
> > The non-NAMED variants are now replaced by user-defined literals using
> the
> > _ns suffix:
> >
> > - NS_LITERAL_CSTRING("foo") becomes "foo"_ns
> > - NS_LITERAL_STRING("bar") becomes u"bar"_ns
> >
> > This makes the string literals somewhat more concise and more consistent
> > with normal literals.
> >
> > Note that the "base" literal needs to use the correct underlying
> character
> > type (char vs. char16_t), which is why the same user-defined literal is
> > used for both cases.
> >
> > For cases where a macro is used to construct a nsString-like literal,
> > either
> > - the definition of the macro can be changed to make use of the
> > user-defined literal already,
> > - the macro can be changed to a constexpr constant
> > - in cases where neither of these is possible or desirable, the (new)
> macro
> > NS_LITERAL_STRING_FROM_CSTRING can be used, which behaves just like
> > NS_LITERAL_STRING did, but has intentionally a somewhat more verbose name
> > to avoid its widespread use where it is not required
> >
> > The NAMED variants have produced a non-standard syntax for declaring
> > variables that are subsequently referenced by user code. These are now
> > replaced by regular variable/constant declarations such as:
> >
> > constexpr auto kNamedCLiteral = "foo"_ns;
> > constexpr auto kNamedLiteral = u"bar"_ns;
> >
> > This is slightly longer than the use of the NAMED macros, but uses a
> > standard syntax.
> >
> > Best wishes
> > Simon
> > ___
> > 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

Re: Changes to string literals

[Frederik Braun]

Thank you Simon, that looks way more ergonomic!
A bummer, I'll have to modify my in-flight patches though :-)

Do you intend to update existing documentation at

(or move it to firefox source docs)?



Am 01.07.20 um 16:53 schrieb Simon Giesecke:
> Hi,
> 
> until Bug 1648010, there were some macros widely used for the handling of
> string literals, i.e. NS_LITERAL_STRING, NS_LITERAL_CSTRING,
> NS_NAMED_LITERAL_STRING, NS_NAMED_LITERAL_CSTRING. These macros have resp.
> will have been removed once all patches for that bug landed.
> 
> The non-NAMED variants are now replaced by user-defined literals using the
> _ns suffix:
> 
> - NS_LITERAL_CSTRING("foo") becomes "foo"_ns
> - NS_LITERAL_STRING("bar") becomes u"bar"_ns
> 
> This makes the string literals somewhat more concise and more consistent
> with normal literals.
> 
> Note that the "base" literal needs to use the correct underlying character
> type (char vs. char16_t), which is why the same user-defined literal is
> used for both cases.
> 
> For cases where a macro is used to construct a nsString-like literal,
> either
> - the definition of the macro can be changed to make use of the
> user-defined literal already,
> - the macro can be changed to a constexpr constant
> - in cases where neither of these is possible or desirable, the (new) macro
> NS_LITERAL_STRING_FROM_CSTRING can be used, which behaves just like
> NS_LITERAL_STRING did, but has intentionally a somewhat more verbose name
> to avoid its widespread use where it is not required
> 
> The NAMED variants have produced a non-standard syntax for declaring
> variables that are subsequently referenced by user code. These are now
> replaced by regular variable/constant declarations such as:
> 
> constexpr auto kNamedCLiteral = "foo"_ns;
> constexpr auto kNamedLiteral = u"bar"_ns;
> 
> This is slightly longer than the use of the NAMED macros, but uses a
> standard syntax.
> 
> Best wishes
> Simon
> ___
> 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