CPU core count game!

[Steve Fink]

Just to drive home a point, let's play a game.

First, guesstimate what percentage of our users have systems with 2 or 
fewer cores.


Then visit https://hardware.metrics.mozilla.com/#goto-cpu-and-memory to 
check your guess.


(I didn't say it was a *fun* game.)


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

How much do we care about pre-Nehalem performance?

[Henri Sivonen]

Do I read agner.org correctly that movdqa was obsoleted by Nehalem,
Silvermont and Bulldozer in the sense that movdqu is no worse than
movdqa on those or later microarchitectures?

Do we have numbers of how our installed base is split between earlier
than Nehalem/Silvermont/Bulldozer vs. Nehalem/Silvermont/Bulldozer or
later?

How much do we care about performance on microarchitectures earlier
than Nehalem/Silvermont/Bulldozer? Would we want more readable,
smaller and on Nehalem/Silvermont/Bulldozer or later potentially a bit
faster code in exchange for a perf regression on
pre-Nehalem/Silvermont/Bulldozer microarchitectures?

(Notably, Core 2 Duo / Penryn at least used to be pretty popular and
predates Nehalem.)

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: nsIClipboardDragDropHooks and nsIClipboardDragDropHookList interfaces

[Masayuki Nakano]

I'd like to remove nsIClipboardDragDropHooks and 
nsIClipboardDragDropHookList interfaces:

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

These interfaces provide ability to override drag and drop operation and 
paste operation on editor. However, currently, this feature isn't used 
by anybody (it seems that it was used by ChatZilla, but according to its 
website, it's not active) and this causes a lot of unnecessary virtual 
calls and QI at D and Paste in editor.  So, I don't think that we 
should keep this feature anymore.


--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The future of "remote XUL"

[Alex Gaynor]

What was the original intended use case for remote XUL, powerful origins
controlled by Mozilla, or enabling developers to build their own powerful
origins?

Alex


On Tue, Mar 27, 2018 at 11:36 AM, Boris Zbarsky  wrote:

> Background: We currently have various provisions for "remote XUL", wherein
> a hostname is whitelisted to:
>
> 1)  Allow parsing XUL coming from that hostname (not normally alllowed for
> the web).
>
> 2)  Allow access to XPConnect-wrapped objects, assuming someone hands out
> such an object.
>
> 3)  Run XBL JS in the same global as the webpage.
>
> 4)  Allow access to a "cut down" Components object, which has
> Components.interfaces but not Components.classes, for example.
>
> This machinery is also used for the "dom.allow_XUL_XBL_for_file"
> preference.
>
> The question is what we want to do with this going forward.  From my point
> of view, I would like to eliminate item 4 above, to reduce complexity.  I
> would also like to eliminate item 2 above, because that would get us closer
> to having the invariant that XPConnect is only used from system
> principals.  These two changes are likely to break some remote XUL
> consumers.
>
> The question is whether we should just go ahead and disable remote XUL
> altogether, modulo its usage in our test suites and maybe
> "dom.allow_XUL_XBL_for_file" (for local testing).  It seems like that might
> be clearer than a dribble of breakage as we remove bits like items 2/4
> above, slowly remove various bindings, slowly remove support for some XUL
> tags, etc...
>
> Thoughts?  My gut feeling is that we should just turn off remote XUL
> outside the IsInAutomation() and maybe the "dom.allow_XUL_XBL_for_file"
> case.
>
> -Boris
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How much do we care about pre-Nehalem performance?

[Henri Sivonen]

On Tue, Mar 27, 2018 at 1:36 PM, Henri Sivonen  wrote:
> Do I read agner.org correctly that movdqa was obsoleted by Nehalem,
> Silvermont and Bulldozer in the sense that movdqu is no worse than
> movdqa on those or later microarchitectures?

http://www.agner.org/optimize/instruction_tables.pdf for the precise
URL I meant.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Unaligned NEON memory access on ARMv7 phones

[Henri Sivonen]

I'm having trouble finding reliable information about the performance
of unaligned NEON memory access on ARMv7 phones.

What I can find is:

 * ARMv7 seems to allow unaligned access to be a trap-to-kernel kind
of performance disaster, but it's hard to find information about
whether the phone SoCs we care about are actually disastrous like
that.

 * On aarch64, unaligned access is the same instruction as aligned
access and gets dynamically penalized, but only minimally, if the
access crosses a cache line boundary. *Presumably* ARMv7 code running
on an ARMv8 core gets the same benefit.

Do we know what performance characteristics we can assume for
unaligned NEON loads/stores on Android phones that have ARMv7 cores
and recent enough Android that Fennec runs in the first place?

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Components and QueryInterface can no longer be used in non-system globals

[Eric Shepherd (Sheppy)]

Ironically, the timing is impressive here. I just this morning noticed that
the tables of inheritance we have in JSON for APIs includes
LegacyQueryInterface among the mixins implemented by a number of
interfaces, and was already in the process of creating a PR to remove that
since it should never have been included in the first place for open web
docs, really.

On Mon, Mar 26, 2018 at 1:55 PM, Boris Zbarsky  wrote:

> I have just landed changes on inbound that restrict WebIDL QueryInterface
> [1] and the Components object [2] to system scopes.
>
> There are two caveats:
>
> 1)  The Components bit is not fully enforced by the security
> infrastructure yet, but those patches are coming in the next day or so. [3].
>
> 2)  "system" in this case includes things that do enablePrivilege.  The
> only consumer blocking this being removed is Talos...
>
> -Boris
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1448397
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1448735 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=1448736
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1389585 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=1389581
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Can we focus more on color management support?

[Emanuel Hoogeveen]

On Friday, March 23, 2018 at 3:56:05 PM UTC+1, justfor...@gmail.com wrote:
> Chrome, Safari treat untagged images as sRGB, can read tagged ICCv4 images 
> and support video color management.
> 
> Firefox does not have these features by default. Any ETA?

Note that (partial?) support for ICCv4 profiles can be enabled in about:config 
by setting gfx.color_management.enablev4 to true, and Firefox can be made to 
treat untagged images like sRGB by setting gfx.color_management.mode to 1.

However I don't think Firefox supports video color management, and I don't 
think the color management code has been touched in years.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

[Myk Melez]

Bobby Holley 
2018 March 12 at 12:25
That's not how I'd define XPCOM - XPCOM existed before XPIDL/XPConnect (and
the name XPConnect means "connecting Javascript to XPCOM"). But quibbling
over the definition isn't really useful.
I was aware that XPCOM predated XPConnect (although I didn't realize 
that it predated XPIDL). Regardless, I agree that quibbling over the 
definition isn't useful. However, it's useful to understand our 
respective definitions, so we know what we're each talking about.



The main platform feature that XPConnect relies upon is the interface
inheritance hierarchy derived from nsISupports, including the
QueryInterface method to bounce between them. Specifically, objects must
implement an interface in that hierarchy to be reflected out-of-the-box by
XPConnect. However, there are lots of bits of C++ code that use
QueryInterface as well, which would be more work to change.
Do any of those bits of C++ code depend on a particular feature of 
XPCOM, or do they just happen to use it to access components whose 
interfaces would just as effectively (modulo the work required to 
convert them) be exposed as concrete native classes?



The nsISupports hierarchy doesn't really cost us anything per se, certainly
not enough to justify the gargantuan task of trying to rip it out. Using it
heavily for performance-critical things can be slow (virtual methods plus
any QI overhead), but we should just fix those callsites when they come up.
There's also a developer ergonomics issue, as Components/QueryInterface 
is more complex and cumbersome than other JS interfaces to native code 
(WebIDL, Node.js Addons, etc.). We've worked around that to some extent 
with Services.jsm and other hacks.



XPConnect's dependency on runtime component registration is limited to the
platform objects we've implemented in JS. If we get rid of those, that
dependency goes away.

There are quite a few of these, if this search is accurate:

https://searchfox.org/mozilla-central/search?q=component.*%5C.js=false=true=*.manifest

And some of them depend on JSMs. Although it isn't clear at first glance 
how significant those dependencies are, nor how much work it would be to 
replace them with C++ or Rust implementations.



XPCOM is a not-very-well-delineated hodgepodge of mostly-independent
things. We are free to modify or remove any pieces that are causing
problems, provided someone can demonstrate that it's worthwhile.
Worthiness is relative to both effort and timeframe. That is to say: if 
something would take a lot of work but would pay off in the long run, 
then it may be worth a long-term (1-3 year) project for a small number 
of engineers, even if it isn't worth a short-term effort that diverts a 
large number of them.


-myk

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

Re: The future of "remote XUL"

[Kris Maglione]

On Tue, Mar 27, 2018 at 03:48:24PM +, Dave Townsend wrote:

My understanding is that it has been effectively unsupported for some time
anyway so I think we should just go ahead and disable it altogether at this
point. If we need bits for automated tests then we should work to switch
tests away from those if we can.


This has been my understanding too. When we removed support for 
remote XUL by default, and then eventually moved it to a site 
whitelist, those were both stepping stones to removing support 
entirely. But it's been officially unsupported since the first 
step, and there hasn't been any way to enable it since we 
removed legacy extension support.


It's also been progressively breaking over time, and I've been 
WONTFIXing bugs about remote XUL with prejudice.


If whatever support is left is causing development friction, we 
should just remove it.



On Tue, Mar 27, 2018 at 8:36 AM Boris Zbarsky  wrote:


Background: We currently have various provisions for "remote XUL",
wherein a hostname is whitelisted to:

1)  Allow parsing XUL coming from that hostname (not normally alllowed
for the web).

2)  Allow access to XPConnect-wrapped objects, assuming someone hands
out such an object.

3)  Run XBL JS in the same global as the webpage.

4)  Allow access to a "cut down" Components object, which has
Components.interfaces but not Components.classes, for example.

This machinery is also used for the "dom.allow_XUL_XBL_for_file"
preference.

The question is what we want to do with this going forward.  From my
point of view, I would like to eliminate item 4 above, to reduce
complexity.  I would also like to eliminate item 2 above, because that
would get us closer to having the invariant that XPConnect is only used
from system principals.  These two changes are likely to break some
remote XUL consumers.

The question is whether we should just go ahead and disable remote XUL
altogether, modulo its usage in our test suites and maybe
"dom.allow_XUL_XBL_for_file" (for local testing).  It seems like that
might be clearer than a dribble of breakage as we remove bits like items
2/4 above, slowly remove various bindings, slowly remove support for
some XUL tags, etc...

Thoughts?  My gut feeling is that we should just turn off remote XUL
outside the IsInAutomation() and maybe the "dom.allow_XUL_XBL_for_file"
case.

-Boris

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

Re: The future of "remote XUL"

[Eric Shepherd (Sheppy)]

I would agree that going all-out and disabling remote XUL entirely makes
the most sense, except in the cases you mention.

The one potential exception: would it make sense to allow it to be enabled
(with it disabled by default) on copies of Firefox set up with Policy
Engine, to allow those users the option?

On Tue, Mar 27, 2018 at 11:36 AM, Boris Zbarsky  wrote:

> Background: We currently have various provisions for "remote XUL", wherein
> a hostname is whitelisted to:
>
> 1)  Allow parsing XUL coming from that hostname (not normally alllowed for
> the web).
>
> 2)  Allow access to XPConnect-wrapped objects, assuming someone hands out
> such an object.
>
> 3)  Run XBL JS in the same global as the webpage.
>
> 4)  Allow access to a "cut down" Components object, which has
> Components.interfaces but not Components.classes, for example.
>
> This machinery is also used for the "dom.allow_XUL_XBL_for_file"
> preference.
>
> The question is what we want to do with this going forward.  From my point
> of view, I would like to eliminate item 4 above, to reduce complexity.  I
> would also like to eliminate item 2 above, because that would get us closer
> to having the invariant that XPConnect is only used from system
> principals.  These two changes are likely to break some remote XUL
> consumers.
>
> The question is whether we should just go ahead and disable remote XUL
> altogether, modulo its usage in our test suites and maybe
> "dom.allow_XUL_XBL_for_file" (for local testing).  It seems like that might
> be clearer than a dribble of breakage as we remove bits like items 2/4
> above, slowly remove various bindings, slowly remove support for some XUL
> tags, etc...
>
> Thoughts?  My gut feeling is that we should just turn off remote XUL
> outside the IsInAutomation() and maybe the "dom.allow_XUL_XBL_for_file"
> case.
>
> -Boris
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>



-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: nsIURI implementations are now threadsafe

[Valentin Gosu]

On 26 March 2018 at 16:53, Ben Kelly  wrote:

> On Mon, Mar 26, 2018 at 10:47 AM, Valentin Gosu 
> wrote:
>
>> Yes, that is definitely something we want to fix, but not very
>> straightforward. We have quite a few URI implementations, and a bunch more
>> protocol handlers.
>>
>> https://github.com/valenting/gecko/wiki/Threadsafe-URIs-prog
>> ress#protocol-handler-implementations
>>
>
> I wonder if it would be worth adding something like:
>
> NS_ThreadsafeNewURI()
>
> That returns an error code if it detects that the URL does not match any
> of the threadsafe URL implementations.  This would allow code to try
> threadsafe parsing first and only fall back to a main thread bounce if its
> an oddball URL.  Right now we hardcode a bunch of http/https/nsStandardURL
> things in various places to accomplish this.
>
>

I think that's a pretty good strategy. It allows us to progressively move
things from nsIProtocolHandler.newURI to NS_ThreadsafeNewURI.



>
>>
>> On 26 March 2018 at 15:24, Ben Kelly  wrote:
>>
>>> Do we have any plan to be able to use NS_NewURI() off-main-thread?  I
>>> thought that was included here, but I see now that it is not.  The initial
>>> URL parse OMT is important for truly being able to remove all our "bounce
>>> to the main thread for URL stuff" legacy code.
>>>
>>> On Fri, Mar 23, 2018 at 8:25 AM, Valentin Gosu 
>>> wrote:
>>>
 Hello everyone,

 I would like to announce that with the landing of bug 1447194, all
 nsIURI
 implementations in Gecko are now threadsafe, as well as immutable. As a
 consequence, you no longer have to clone a URI when you pass it around,
 as
 it's guaranteed not to change, and now it's OK to release them off the
 main
 thread.

 If you need to change a nsIURI, you should use the nsIURIMutator
 interface
 (in JavaScript - just call .mutate() on the URI) or the NS_MutateURI
 
 helper class (in C++).

 More info here:
 https://wiki.mozilla.org/Necko/nsIURI

 If you find any bugs, make them block bug 922464 (OMT-nsIURI)

 I'd like to thank everyone who helped review the patches, especially
 Honza
 Bambas who reviewed most of my patches.

 Cheers!
 ___
 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: The future of "remote XUL"

[Nicholas Alexander]

Hi Boris!

On Tue, Mar 27, 2018 at 8:36 AM, Boris Zbarsky  wrote:

> Background: We currently have various provisions for "remote XUL", wherein
> a hostname is whitelisted to:
>
> 1)  Allow parsing XUL coming from that hostname (not normally alllowed for
> the web).
>
> 2)  Allow access to XPConnect-wrapped objects, assuming someone hands out
> such an object.
>
> 3)  Run XBL JS in the same global as the webpage.
>
> 4)  Allow access to a "cut down" Components object, which has
> Components.interfaces but not Components.classes, for example.
>
> This machinery is also used for the "dom.allow_XUL_XBL_for_file"
> preference.
>
> The question is what we want to do with this going forward.  From my point
> of view, I would like to eliminate item 4 above, to reduce complexity.  I
> would also like to eliminate item 2 above, because that would get us closer
> to having the invariant that XPConnect is only used from system
> principals.  These two changes are likely to break some remote XUL
> consumers.
>
> The question is whether we should just go ahead and disable remote XUL
> altogether, modulo its usage in our test suites and maybe
> "dom.allow_XUL_XBL_for_file" (for local testing).  It seems like that might
> be clearer than a dribble of breakage as we remove bits like items 2/4
> above, slowly remove various bindings, slowly remove support for some XUL
> tags, etc...
>
> Thoughts?  My gut feeling is that we should just turn off remote XUL
> outside the IsInAutomation() and maybe the "dom.allow_XUL_XBL_for_file"
> case.
>

I am not expert in this area, but this sounds like a vestigial feature of
the Mozilla XUL application layer that should be removed immediately.  Can
you elaborate on:

- some of the details of "likely to break remote XUL consumers"?  Which
consumers are these -- internal?  External?
- do we have an estimate of how much remote XUL is used in our own test
suite?  Is this days/weeks/months of labour to replace?
- do we have any idea of the popularity of `dom.allow_XUL_XBL_for_file`?
Do we expect this usage is all internal?  (I really hope so!)

Sorry to ask for work (before you do the real work),
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: nsIURI implementations are now threadsafe

[Ben Kelly]

On Mon, Mar 26, 2018 at 10:47 AM, Valentin Gosu 
wrote:

> Yes, that is definitely something we want to fix, but not very
> straightforward. We have quite a few URI implementations, and a bunch more
> protocol handlers.
>
> https://github.com/valenting/gecko/wiki/Threadsafe-URIs-
> progress#protocol-handler-implementations
>

I wonder if it would be worth adding something like:

NS_ThreadsafeNewURI()

That returns an error code if it detects that the URL does not match any of
the threadsafe URL implementations.  This would allow code to try
threadsafe parsing first and only fall back to a main thread bounce if its
an oddball URL.  Right now we hardcode a bunch of http/https/nsStandardURL
things in various places to accomplish this.


>
>
> On 26 March 2018 at 15:24, Ben Kelly  wrote:
>
>> Do we have any plan to be able to use NS_NewURI() off-main-thread?  I
>> thought that was included here, but I see now that it is not.  The initial
>> URL parse OMT is important for truly being able to remove all our "bounce
>> to the main thread for URL stuff" legacy code.
>>
>> On Fri, Mar 23, 2018 at 8:25 AM, Valentin Gosu 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> I would like to announce that with the landing of bug 1447194, all nsIURI
>>> implementations in Gecko are now threadsafe, as well as immutable. As a
>>> consequence, you no longer have to clone a URI when you pass it around,
>>> as
>>> it's guaranteed not to change, and now it's OK to release them off the
>>> main
>>> thread.
>>>
>>> If you need to change a nsIURI, you should use the nsIURIMutator
>>> interface
>>> (in JavaScript - just call .mutate() on the URI) or the NS_MutateURI
>>> >> test/TestURIMutator.cpp#22>
>>> helper class (in C++).
>>>
>>> More info here:
>>> https://wiki.mozilla.org/Necko/nsIURI
>>>
>>> If you find any bugs, make them block bug 922464 (OMT-nsIURI)
>>>
>>> I'd like to thank everyone who helped review the patches, especially
>>> Honza
>>> Bambas who reviewed most of my patches.
>>>
>>> Cheers!
>>> ___
>>> 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

Intent to unship: nsIEditor.numberOfUntoItems and nsIEditor.numberOfRedoItems

[Masayuki Nakano]

A patch to remove nsIEditor.numberOfUntoItems and 
nsIEditor.numberOfRedoItems are now landed:

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

As far as I've investigated, nobody (including comm-central and 
bluegriffon) uses these XPCOM methods since those methods exactly equal 
to nsIEditor.transactionManager.numberOfUntoItems and 
nsIEditor.transactionManager.numberOfRedoItems.


So, we don't need to keep maintaining these shortcut methods anymore.

--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Browser Architecture Newsletter 6 (S02E01)

[Nicholas Alexander]

FADE IN

DINGY OFFICE INTERIOR

Camera zooms out to reveal BROWSER ARCHITECTURE ENGINEER, typing furiously.

It’s S02E01 of  Browser Architecture Newsletters!

Desktop Technology Stack

The Browser Architecture group is working hard to tackle some large
problems with the technology stack used to build Desktop Firefox.

XBL Replacement

The latest updates can be found in our spin-off, XBL Replacement Newsletter
S01E04
. In
addition to that:

   -

   You may have seen lots of activity lately on the de-xbl metabug
   . That’s because
   :enn, :paolo, and :timdream have been given starring roles on the project!
   -

   Now that tabbrowser is no longer implemented with XBL, :dao has driven
   forward a bunch of long-needed cleanups to gBrowser. He simplified
    the
   initialization process and extracted the async tab switcher
    and tab progress
   listener  into
   separate modules. This work caused a tabpaint improvement
    on talos and
   fixed at least one race condition
    caused by XBL
   constructors.

Overlays

XUL overlays have been written out of this season!  You might remember
overlays from such timeless frustrations as trying to understand how
Firefox menus and hotkeys are combined, which is partially described by the
following diagram:

:bdahl has completely removed overlays, and you can binge-watch the carnage
in the tracking spreadsheet

!

XUL removal

The Browser Architecture team is beginning to focus on the larger goal
after XBL replacement -- XUL removal.  This is a large (!) and hairy (!!)
area, so :bgrins wrote the first draft of a screenplay

discussing how we might tackle the beast.  There’s a metabug on file to
remove in-content XUL ,
which is likely to be one of the first parts to hit the cutting room floor.

Fluent

Fluent is working hard to win the hearts of the audience. It’s currently
only starring in small film festivals like Firefox Preferences
, but it seems to
work well with the XBL removal, and has led to some nice cleanups in the JS
code all around the component.

Using some pretty rough estimations we started the cycle with close to 700
DTD entries, landed removal of 300 of them, and have removal of another 200
under review right now. At this pace people have started murmuring about
Preferences becoming DTD free by the time Firefox 61 hits beta!

Sync.next

Prototyping of new sync approaches based on top of a new storage system
continues.  There are some great 15-30 minute show

and tell

video

recordings

(sadly, Flash is required to watch). Q2 OKR planning for the Sync team is
eagerly scoping out a better future and how to get there.  Look for the
companion newsletter (a mini-series?) in the near future.

rkv

We recently reviewed a proposal to migrate storage currently (ab)using ad
hoc flat files, JSON files, preferences etc. to a lightweight Rust
key-value store built on top of LMDB, netting us a faster, more durable,
multi-process and cross-platform storage capability.  The review was
largely a success (link to follow); the next steps are to move forward with
thorough documentation and guidance for consumers, evaluate outstanding
open questions (particularly around verifying platform support), and then
to begin work on shipping vehicles within Firefox. We're initially looking
at XULStore and the search cache as suitable candidates. You can track this
work in the repo  and
the initial WIP landing bug
.

How We Work

Browser Architecture is also investigating less technical ways to increase
Firefox’s engineering velocity.

Modernization to reflect Firefox technical leadership in the module
ownership system

As described in a governance mailing list post
,
“We propose to restructure the Firefox-related modules under control of a
new “Technical Leadership Module Committee” (TLMC).”  Our own Dave 

Re: PSA: nsIURI implementations are now threadsafe

[Valentin Gosu]

Yes, that is definitely something we want to fix, but not very
straightforward. We have quite a few URI implementations, and a bunch more
protocol handlers.

https://github.com/valenting/gecko/wiki/Threadsafe-URIs-progress#protocol-handler-implementations


On 26 March 2018 at 15:24, Ben Kelly  wrote:

> Do we have any plan to be able to use NS_NewURI() off-main-thread?  I
> thought that was included here, but I see now that it is not.  The initial
> URL parse OMT is important for truly being able to remove all our "bounce
> to the main thread for URL stuff" legacy code.
>
> On Fri, Mar 23, 2018 at 8:25 AM, Valentin Gosu 
> wrote:
>
>> Hello everyone,
>>
>> I would like to announce that with the landing of bug 1447194, all nsIURI
>> implementations in Gecko are now threadsafe, as well as immutable. As a
>> consequence, you no longer have to clone a URI when you pass it around, as
>> it's guaranteed not to change, and now it's OK to release them off the
>> main
>> thread.
>>
>> If you need to change a nsIURI, you should use the nsIURIMutator interface
>> (in JavaScript - just call .mutate() on the URI) or the NS_MutateURI
>> > test/TestURIMutator.cpp#22>
>> helper class (in C++).
>>
>> More info here:
>> https://wiki.mozilla.org/Necko/nsIURI
>>
>> If you find any bugs, make them block bug 922464 (OMT-nsIURI)
>>
>> I'd like to thank everyone who helped review the patches, especially Honza
>> Bambas who reviewed most of my patches.
>>
>> Cheers!
>> ___
>> 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: The future of "remote XUL"

[Dave Townsend]

My understanding is that it has been effectively unsupported for some time
anyway so I think we should just go ahead and disable it altogether at this
point. If we need bits for automated tests then we should work to switch
tests away from those if we can.

On Tue, Mar 27, 2018 at 8:36 AM Boris Zbarsky  wrote:

> Background: We currently have various provisions for "remote XUL",
> wherein a hostname is whitelisted to:
>
> 1)  Allow parsing XUL coming from that hostname (not normally alllowed
> for the web).
>
> 2)  Allow access to XPConnect-wrapped objects, assuming someone hands
> out such an object.
>
> 3)  Run XBL JS in the same global as the webpage.
>
> 4)  Allow access to a "cut down" Components object, which has
> Components.interfaces but not Components.classes, for example.
>
> This machinery is also used for the "dom.allow_XUL_XBL_for_file"
> preference.
>
> The question is what we want to do with this going forward.  From my
> point of view, I would like to eliminate item 4 above, to reduce
> complexity.  I would also like to eliminate item 2 above, because that
> would get us closer to having the invariant that XPConnect is only used
> from system principals.  These two changes are likely to break some
> remote XUL consumers.
>
> The question is whether we should just go ahead and disable remote XUL
> altogether, modulo its usage in our test suites and maybe
> "dom.allow_XUL_XBL_for_file" (for local testing).  It seems like that
> might be clearer than a dribble of breakage as we remove bits like items
> 2/4 above, slowly remove various bindings, slowly remove support for
> some XUL tags, etc...
>
> Thoughts?  My gut feeling is that we should just turn off remote XUL
> outside the IsInAutomation() and maybe the "dom.allow_XUL_XBL_for_file"
> case.
>
> -Boris
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue

[Anne van Kesteren]

On Fri, Mar 23, 2018 at 9:16 PM, L. David Baron  wrote:
> I should clarify that it isn't actually non-standard:  it was part
> of DOM Level 2:
> https://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSStyleDeclaration
> but ended up never being widely implemented.  It's not a
> particularly nice API, nor was it specified in a way that could lead
> to interoperability, and its replacement is intended to be
> https://drafts.css-houdini.org/css-typed-om/ .
>
> I'm still in favor of removing it.

FWIW, note https://lists.w3.org/Archives/Public/www-style/2003Oct/0347.html
and https://www.w3.org/TR/2011/WD-cssom-20110712/#history which aimed
to replace the document you reference. Maybe not quite non-standard,
but definitely some flavor of obsolete.


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

Re: PSA: nsIURI implementations are now threadsafe

[Ben Kelly]

This is so great.  Thank you!

One question that comes to mind, though, is there any chance this could be
uplifted to 60?  As we start doing more OMT nsIURI stuff its going to
become difficult to uplift code to 60ESR.

On Fri, Mar 23, 2018 at 8:25 AM, Valentin Gosu 
wrote:

> Hello everyone,
>
> I would like to announce that with the landing of bug 1447194, all nsIURI
> implementations in Gecko are now threadsafe, as well as immutable. As a
> consequence, you no longer have to clone a URI when you pass it around, as
> it's guaranteed not to change, and now it's OK to release them off the main
> thread.
>
> If you need to change a nsIURI, you should use the nsIURIMutator interface
> (in JavaScript - just call .mutate() on the URI) or the NS_MutateURI
>  TestURIMutator.cpp#22>
> helper class (in C++).
>
> More info here:
> https://wiki.mozilla.org/Necko/nsIURI
>
> If you find any bugs, make them block bug 922464 (OMT-nsIURI)
>
> I'd like to thank everyone who helped review the patches, especially Honza
> Bambas who reviewed most of my patches.
>
> Cheers!
> ___
> 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: Intent to unprefix: ::-moz-selection.

[Emilio Cobos Álvarez]

On 3/26/18 4:13 PM, Boris Zbarsky wrote:

On 3/26/18 3:16 AM, Emilio Cobos Álvarez wrote:

However other engines have shipped this unprefixed for a long time with
the same semantics that we implement


https://bugzilla.mozilla.org/show_bug.cgi?id=509958#c14 claims the 
semantics are not actually quite the same.  Have we done some testing 
here?  Including on Edge?


So, when I went through the bug I didn't know at all what that comment 
was about (and the account that posted it was gone so couldn't ask), but 
it seems we don't respect the ::selection background when selecting images.


That looks like an easy fix though, I'll ensure it gets fixed before 
landing. Filed bug 1449010.


It would be best to just have matching 
semantics, instead of unprefixing with slightly different behavior.


Haven't tested Edge (because I don't have it locally), but will make 
sure that gets done before landing that patch.


 -- Emilio


-Boris
___
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: The future of "remote XUL"

[Boris Zbarsky]

On 3/27/18 11:49 AM, Alex Gaynor wrote:
What was the original intended use case for remote XUL, powerful origins 
controlled by Mozilla, or enabling developers to build their own 
powerful origins?


The latter.  In particular, it was used for intranet apps.

Note that the remote XUL origins are not terribly powerful.  They do 
_not_ allow arbitrary XPCOM access, for instance...  They do have more 
attack surface than normal web pages, of course.


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

Re: The future of "remote XUL"

[Boris Zbarsky]

On 3/27/18 12:39 PM, Alex Gaynor wrote:

Do we have any telemetry on whether people actually use it?


I don't believe we do.


Are there any reasons to want to keep it around, besides backwards 
compatibility?


Ease of writing tests and debugging XUL stuff (hence the thought to 
maybe keep it for the "allow XUL for file://" case).


Apart from that, I can't think of anything.

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

Re: PSA: nsIURI implementations are now threadsafe

[Boris Zbarsky]

On 3/23/18 8:25 AM, Valentin Gosu wrote:

I would like to announce that with the landing of bug 1447194, all nsIURI
implementations in Gecko are now threadsafe, as well as immutable.


Valentin,

Thank you very much for doing this!  Just the safety guarantees from URI 
immutability are a huge deal.


Of course the threadsafety is nice too.  ;)

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

Re: The future of "remote XUL"

[Boris Zbarsky]

On 3/27/18 11:50 AM, Eric Shepherd (Sheppy) wrote:
The one potential exception: would it make sense to allow it to be 
enabled (with it disabled by default) on copies of Firefox set up with 
Policy Engine, to allow those users the option?


That would require maintaining the remote XUL infrastructure we have 
now, so doesn't seem like a win from the point of view of code or 
invariant simplification...


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

Re: The future of "remote XUL"

[Boris Zbarsky]

On 3/27/18 12:56 PM, Brian Grinstead wrote:
Wouldn't keeping it for file:// require us to maintain the infrastructure, or is there something that makes it worse in the whitelisted domain case? 


It's a question of what guarantees we offer for XUL working.

Keeping it for file:// requires keeping some of the infrastructure for 
parsing XUL and maybe loading XBL if the pref is flipped.


It does not require us to provide access to Components.interfaces or 
allow exposure of XPCOM things in those file:// URLs, as long as we're 
OK with "not all XUL" working in the file:// context.  Which we are.


Supporting remote XUL in general, on the other hand, involves not 
breaking compat with already-deployed stuff which may be relying on the 
XPCOM object exposure.


So we could have meaningful code removal and invariant strengthening 
even while keeping the file:// case.  Certainly until we sort out our 
test suites there's no _extra_ win from removing the file:// case in 
terms of code removal (though again invariants can maybe be somewhat 
stronger if we do remove it).



Also, do we load pages in the content process in both cases?


I believe we do, but I have not verified.


I’m inclined to say we should remove it for the file:// as well


OK.  Just to be clear, if we expect layout hackers to debug XUL issues, 
the file:// case is really useful for that, because it allows using the 
layout debugger.  I we promise to not make them do that, we can probably 
remove the file:// case.



It’s not nearly as convenient, but test cases can still be created by 
registering the xul file as a chrome uri and loading it in a tab.


Can't do that in the layout debugger, yes?

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

The future of "remote XUL"

[Boris Zbarsky]

(I tried to send this to dev-platform@lists.mozilla.org, but tha's not 
coming through for some reason  There is parallel discussion in 
firefox-dev if people want to try to track both.)


Background: We currently have various provisions for "remote XUL", 
wherein a hostname is whitelisted to:


1)  Allow parsing XUL coming from that hostname (not normally alllowed 
for the web).


2)  Allow access to XPConnect-wrapped objects, assuming someone hands 
out such an object.


3)  Run XBL JS in the same global as the webpage.

4)  Allow access to a "cut down" Components object, which has 
Components.interfaces but not Components.classes, for example.


This machinery is also used for the "dom.allow_XUL_XBL_for_file" preference.

The question is what we want to do with this going forward.  From my 
point of view, I would like to eliminate item 4 above, to reduce 
complexity.  I would also like to eliminate item 2 above, because that 
would get us closer to having the invariant that XPConnect is only used 
from system principals.  These two changes are likely to break some 
remote XUL consumers.


The question is whether we should just go ahead and disable remote XUL 
altogether, modulo its usage in our test suites and maybe 
"dom.allow_XUL_XBL_for_file" (for local testing).  It seems like that 
might be clearer than a dribble of breakage as we remove bits like items 
2/4 above, slowly remove various bindings, slowly remove support for 
some XUL tags, etc...


Thoughts?  My gut feeling is that we should just turn off remote XUL 
outside the IsInAutomation() and maybe the "dom.allow_XUL_XBL_for_file" 
case.


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

The future of "remote XUL"

[Boris Zbarsky]

Background: We currently have various provisions for "remote XUL", 
wherein a hostname is whitelisted to:


1)  Allow parsing XUL coming from that hostname (not normally alllowed 
for the web).


2)  Allow access to XPConnect-wrapped objects, assuming someone hands 
out such an object.


3)  Run XBL JS in the same global as the webpage.

4)  Allow access to a "cut down" Components object, which has 
Components.interfaces but not Components.classes, for example.


This machinery is also used for the "dom.allow_XUL_XBL_for_file" preference.

The question is what we want to do with this going forward.  From my 
point of view, I would like to eliminate item 4 above, to reduce 
complexity.  I would also like to eliminate item 2 above, because that 
would get us closer to having the invariant that XPConnect is only used 
from system principals.  These two changes are likely to break some 
remote XUL consumers.


The question is whether we should just go ahead and disable remote XUL 
altogether, modulo its usage in our test suites and maybe 
"dom.allow_XUL_XBL_for_file" (for local testing).  It seems like that 
might be clearer than a dribble of breakage as we remove bits like items 
2/4 above, slowly remove various bindings, slowly remove support for 
some XUL tags, etc...


Thoughts?  My gut feeling is that we should just turn off remote XUL 
outside the IsInAutomation() and maybe the "dom.allow_XUL_XBL_for_file" 
case.


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

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

[Boris Zbarsky]

On 3/26/18 6:29 PM, Myk Melez wrote:
Do any of those bits of C++ code depend on a particular feature of 
XPCOM


They depend on the dynamic casting provided by QueryInterface.

That said, they could in many cases switch to other methods of dynamic 
casting that are more limited...


or do they just happen to use it to access components whose 
interfaces would just as effectively (modulo the work required to 
convert them) be exposed as concrete native classes?


That happens as well.

There's also a developer ergonomics issue, as Components/QueryInterface 
is more complex and cumbersome than other JS interfaces to native code 
(WebIDL, Node.js Addons, etc.).


Note that XPConnect did support other ways of exposing things like 
constructors, at least on Window instances.  Ways we recently removed, 
because implementing the back end of such things was painful enough that 
nothing except the DOM (broadly speaking, as in web-exposed stuff) 
bothered to in practice, and the DOM is now on WebIDL.



We've worked around that to some extent with Services.jsm and other hacks.


I think we should think about other ways to address such pain points as 
needed.  Please file blockers for 
https://bugzilla.mozilla.org/show_bug.cgi?id=1444515



XPConnect's dependency on runtime component registration is limited to the
platform objects we've implemented in JS. If we get rid of those, that
dependency goes away.

There are quite a few of these, if this search is accurate:


Yes, there are.

Worthiness is relative to both effort and timeframe. That is to say: if 
something would take a lot of work but would pay off in the long run, 
then it may be worth a long-term (1-3 year) project for a small number 
of engineers, even if it isn't worth a short-term effort that diverts a 
large number of them.


I think we all agree on that.  The devil is in the details.  ;)

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

Re: The future of "remote XUL"

[Boris Zbarsky]

On 3/27/18 1:02 PM, Eric Shepherd wrote:
​Yes, that's true. My thinking is that a first step could be to change 
it so it had to be enabled using Policy Engine, and have an ESR release 
with that


So presumably targeting 60?  The timing is a bit tight...

Note that as things stand the only way to enable remote XUL for a 
hostname is by adding permission manager entries.  This needs to either 
be done by a non-webextension extension, or by running code in a 
privileged context (e.g. browser console) or by directly munging the 
sqlite database involved.  This last is what we do in our automation.


with a notice to users of ESR that that will be the last ESR 
release to support remote XUL.


We can do that anyway, for 60, without changing how it's enabled, right?

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

Re: The future of "remote XUL"

[Boris Zbarsky]

On 3/27/18 11:50 AM, Nicholas Alexander wrote:
- some of the details of "likely to break remote XUL consumers"?  Which 
consumers are these -- internal?  External?


This is referring to my proposed XPConnect/Components changes, right?

External.  We have no internal consumers of remote XUL outside our test 
suite, and obviously I would fix the tests as needed (there's not much 
needed).


- do we have an estimate of how much remote XUL is used in our own test 
suite?


https://searchfox.org/mozilla-central/search?q=.xul=false=false=mochitest.ini 
shows 8 mochitests using it.


https://searchfox.org/mozilla-central/search?q=.xul=reftest.list 
shows 280-ish reftests using it, mostly testing actual XUL layout 
functionality.


https://searchfox.org/mozilla-central/search?q=.xul=false=false=crashtests.list 
shows ~170 crashtests that are XUL files.


https://searchfox.org/mozilla-central/search?q=%3Cbindings=test 
shows ~220 XBL files used in tests, though some of those overlap with 
one of the earlier lists (e.g. XBL being pulled in by a .xul test). 
Presumably we need to address these anyway for XBL removal.


There might be some other bits I'm missing (e.g. browser tests loading 
XUL files in tabs or something), but the above seems like a bare minimum 
estimate for the usage.



Is this days/weeks/months of labour to replace?


Definitely not days.  Probably doable in "weeks", though a lot of that 
depends on what we replace with.  Presumably chrome tests loaded with 
system principal to replace the mochitests (including the ones using 
XBL); that one is not hard to do, but will need auditing the tests to 
make sure they still make sense in the aftermath.  For the reftests and 
crashtests, we need to figure out the right replacement.


- do we have any idea of the popularity of 
`dom.allow_XUL_XBL_for_file`?  Do we expect this usage is all internal?  
(I really hope so!)


I don't, and I really hope so too


Sorry to ask for work (before you do the real work),


Nah, all your questions are totally reasonable.  ;)

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

Re: Style proposal: char32_t for Unicode scalar values

[Boris Zbarsky]

On 3/26/18 1:48 AM, Henri Sivonen wrote:

Rationale: Say what you mean when the language has vocabulary to do so.


Amen.  I'd be happy with char32_t for scalar values.

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

Re: PSA: nsIURI implementations are now threadsafe

[Ben Kelly]

Do we have any plan to be able to use NS_NewURI() off-main-thread?  I
thought that was included here, but I see now that it is not.  The initial
URL parse OMT is important for truly being able to remove all our "bounce
to the main thread for URL stuff" legacy code.

On Fri, Mar 23, 2018 at 8:25 AM, Valentin Gosu 
wrote:

> Hello everyone,
>
> I would like to announce that with the landing of bug 1447194, all nsIURI
> implementations in Gecko are now threadsafe, as well as immutable. As a
> consequence, you no longer have to clone a URI when you pass it around, as
> it's guaranteed not to change, and now it's OK to release them off the main
> thread.
>
> If you need to change a nsIURI, you should use the nsIURIMutator interface
> (in JavaScript - just call .mutate() on the URI) or the NS_MutateURI
>  TestURIMutator.cpp#22>
> helper class (in C++).
>
> More info here:
> https://wiki.mozilla.org/Necko/nsIURI
>
> If you find any bugs, make them block bug 922464 (OMT-nsIURI)
>
> I'd like to thank everyone who helped review the patches, especially Honza
> Bambas who reviewed most of my patches.
>
> Cheers!
> ___
> 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