Re: Deprecating XUL in new UI

[Boris Zbarsky]

On 1/23/17 10:31 AM, David Bolter wrote:

Should (can) it die in the Quantum development timeframe?


In my opinion, no.


What does that do to shipping risk?


Makes it super-high.


I realize churn creates risk, but I seem to recall XBL
is getting in the way for Quantum styling?


Not as much as having to rewrite all our in-tree XBL in not-yet-existing 
technologies would get in the way...


-Boris

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

Re: Intent to ship: support "basic shapes" for the CSS 'clip-path' property

[Boris Zbarsky]

On 2/7/17 3:03 AM, Ku(顧思捷)CJ wrote:

  https://drafts.fxtf.org/css-masking-1/#the-clip-path
  https://drafts.csswg.org/css-shapes-1/#supported-basic-shapes


How stable are these specs?  They don't seem to be anywhere near CR, and 
while I realize that's not a requirement, it would be good to have them 
be at a _slightly_ higher maturity level than "whatever the editors 
wrote today" [1]


-Boris

[1] Literally; one of them was last modified today.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: CSS text-justify property

[Boris Zbarsky]

On 2/8/17 5:08 AM, Jeremy Chen wrote:

Link to standard: https://drafts.csswg.org/css-text-3/#text-justify-property


How stable is this spec?

Note that even if it's unstable that shouldn't stop us implementing; 
that mostly affects shipping.  So as long as we're pretty sure that the 
basic set of functionality is stable, even if the actual names of the 
values are not, implementing makes sense.


-Boris

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

Re: Intent to implement and ship: document.origin

[Boris Zbarsky]

I would like to revive this intent.  At this point estimated release 
would be 54, and Blink has shipped this a while ago.


The state of things here is as follows:

1)  location.origin still exists and sites use it, so we can't remove 
it.  But we can deprecate it if we want.


2)  document.origin is in the spec and shipping in Safari and Chrome. 
Except the Safari version doesn't match the spec at all... 
https://bugs.webkit.org/show_bug.cgi?id=168022 filed.  Edge 14 doesn't 
seem to support this; I don't know about their developer preview.


3)  The spec also defines self.origin (in both workers and windows, for 
consistent API).  For the window case it returns the origin of the 
active document.  No one else implements this yet; I will be sending a 
separate intent for this.


-Boris

On 12/1/14 10:09 AM, Boris Zbarsky wrote:

Summary: document.origin returns the Unicode serialization of the
document's origin.  The returned value does not depend on what
document.domain was set to.

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

Spec: http://dom.spec.whatwg.org/#dom-document-origin

Platform coverage: All of them.

Estimated release: 37

I don't plan to put this behind a pref.  It's trivial to back out if
need be.

Blink is considering implementing this too, and they're trying to find
out whether we plan to implement.  I think this is a useful feature and
we should add it.

The only caveat is possible confusion due to the difference between
document.origin and location.origin; I'm a bit torn about what to do
about that, if anything, short of removing location.origin

-Boris


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

Intent to implement and ship: self.origin

[Boris Zbarsky]

Summary: self.origin returns the Unicode serialization of the origin of 
the settings object of the global represented by "self" (a Window or 
WorkerGlobalScope).  This gives scripts a consistent way of getting 
their origin in both situations.  Note that unlike location.origin this 
represents the actual origin of the global, not the origin of the URL 
it's loaded from.  The difference can be substantial in the case of 
sandboxing, for example.


In the window case, this returns the same thing as self.document.origin 
if document.origin is also implemented.


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

Spec: https://html.spec.whatwg.org/multipage/webappapis.html#dom-origin

Platfrom coverage: All

Estimated release: 54

Preference: none.

Devtools bug: None needed, I think.

Status in other implementations: no one else implements this yet.  I am 
not aware of either WebKit or Blink bugs to implement this either.  I 
just filed https://bugs.webkit.org/show_bug.cgi?id=168023 and 
https://bugs.chromium.org/p/chromium/issues/detail?id=690195 bug have no 
idea whether they will actually pick them up.


Tests: I will make sure there are some.  ;)

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

Re: Intent to implement and ship: document.origin

[Boris Zbarsky]

On 2/9/17 5:44 AM, Mike West wrote:

Perhaps we could deprecate `document.origin` and ship `self.origin` in
Blink instead of y'all shipping `document.origin`?


Given the lack of support in Edge and the incompatible support in 
WebKit, I can probably live with that.  Especially if y'all remove it in 
a reasonably short timeframe.  ;)



It seems like we want to encourage folks to use `self.origin` going forward...


I agree.

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

Re: Intent to implement and ship: document.origin

[Boris Zbarsky]

On 2/9/17 5:44 AM, Mike West wrote:

Perhaps we could deprecate `document.origin` and ship `self.origin` in
Blink instead of y'all shipping `document.origin`? It seems like we want to
encourage folks to use `self.origin` going forward...


So specifically, should I be asking Anne to remove document.origin from 
the spec?


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

Re: Intent to implement and ship: self.origin

[Boris Zbarsky]

On 2/9/17 5:45 AM, Mike West wrote:

I look forward to stealing your tests. :)


Yep, sounds good.  I put up patches in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1306170 with the test bits; 
in fact most of the patches are changes to the tests.  Note that you'll 
want https://github.com/w3c/testharness.js/pull/242 and 
https://github.com/w3c/testharness.js/pull/241 too (included in those 
patches).


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

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Boris Zbarsky]

On 2/10/17 8:03 PM, Mats Palmgren wrote:

I'm guessing Firefox add-ons might not bother with anything but
-moz-appearance though,  but I assume those counts as chrome sheets,
so the property will continue to work there as before. (Please correct me
if I'm wrong about that.)


"Chrome sheets", for purposes of this discussion are sheets whose URI 
starts with "chrome://".


The biggest worry for me is that inline style is never a "chrome sheet" 
in this sense.


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

Re: Intent to unship: xml:base attribute

[Boris Zbarsky]

On 2/16/17 7:12 AM, Xidorn Quan wrote:

The perf penalty of xml:base is basically that we have to dynamically
construct a URL from bottom to top along the tree whenever we need a
base URL of an element. And since this URL may be constructed
dynamically, the caller would have to hold a strong reference to it, and
thus an additional refcount manipulation. So a URL not dynamically
generated would be enough to avoid that penalty.


I assume this means that the Get/SetExplicitBaseURI API on nsINode is 
still OK?


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

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Boris Zbarsky]

On 2/16/17 10:23 AM, Mats Palmgren wrote:

That's a valid concern, but I think ignoring -moz-appearance has fairly
benign effects in most cases.


Well, as in things just look wrong, is all, right?


And as Jet pointed out to me, just landing
it and see what breaks is standard procedure for unprefixing properties:
https://bugzilla.mozilla.org/show_bug.cgi?id=775235


For addons we can do better: we can just contact them about it.  Please 
talk to :jorgev.


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

Re: Intent to unship: xml:base attribute

[Boris Zbarsky]

On 2/16/17 5:52 PM, Xidorn Quan wrote:

Is there any reason you think we should keep the Get/SetExplicitBaseURI
API?


As long as we can address its current users in some other way, no.

-Boris


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

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Boris Zbarsky]

On 2/16/17 6:54 PM, Mats Palmgren wrote:

I don't think removing -moz-appearance even has the potential of being
"critical".  All that happens is that you get native styling instead
(at worst).  There shouldn't be any loss of function.


That depends.  It's not hard to come up with examples where doing that 
means you can't read any of the labels on the buttons you're supposed to 
click.


I thought about this a fair bit the last few days, and I think it would 
be a mistake to tie shipping appearance/-webkit-appearance to the 
removal of -moz-appearance.  We should ship the no-prefix version and 
the -webkit version.  Then we should get people to switch to them.  Then 
we can remove -moz-appearance.



I suspect this is the case for -moz-appearance.  If the web author also
wrote -webkit-appearance/appearance:none (as they should)


I'm 99% sure there are pages (including some produced by Google and 
Facebook, last I checked) that do server-side sniffing and send only 
-moz-appearance to Firefox and only -webkit-appearance to Chrome and 
"appearance" to no one at all.



AFAICT, IE11 (on a Win7 desktop) has no support for 'appearance' at all
(or any prefixed variant thereof), and Edge specifically added support
only for '-webkit-appearance:none'.  And I assume the web still works
in those browsers.


Edge also has a UA string that sniffs as "Chrome" unless you very 
carefully try to disambiguate.  This is not an accident.


-Boris

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

Re: Should &&/|| really be at the end of lines?

[Boris Zbarsky]

On 2/17/17 5:44 PM, gsquel...@mozilla.com wrote:

- People who stick with the official parser will only ever see that (pushing to 
mozreview will reformat everything to the official style).


Not all reviews go through mozreview.

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

Re: Please consider whether new APIs/functionality should be disabled by default in sandboxed iframes

[Boris Zbarsky]

On 2/27/17 7:07 AM, David Bruant wrote:

Did a particular feature triggered your message?


No, it was just something I had been thinking about for a bit.


Would it make sense to add the question to the "Intent to Implement" email 
template?
https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement


That's probably a good idea.  I added it there:

   Is this feature enabled by default in sandboxed iframes? If not, is 
there a proposed sandbox flag to enable it? If allowed, does it preserve 
the current invariants in terms of what sandboxed iframes can do?


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

Re: Intent to ship: WebVR on Windows in Release

[Boris Zbarsky]

On 3/1/17 3:50 PM, kgilb...@mozilla.com wrote:

As of March 1, 2017 I intend to turn WebVR on by default on Windows.


So flip the pref on Windows only, right?

If there is no VR hardware, is the idea that navigator.getVRDisplays() 
returns a promise resolving to an empty array?



Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/


It's a bit worrying to me that this spec is not written down in 
sufficient detail to be implemented interoperably [1].  How confident 
are we that what the other browsers are shipping matches what we're 
shipping?  Are there web platform tests?


-Boris

[1]  For example, what does the VRFrameData constructor actually do? 
The spec doesn't define it at all.  Where is the VRPose inside supposed 
to come from?  What values will it contain?  I filed 
https://github.com/w3c/webvr/issues/195 on this, but note that I've 
spent all of about 5 minutes skimming the spec and ran into this.  I 
have _not_ done a careful read looking for possible interop problems...

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

Re: Intent to ship: WebVR on Windows in Release

[Boris Zbarsky]

On 3/1/17 5:03 PM, Kip Gilbert wrote:

We have worked directly with the other WebVR platform implementers to ensure 
compatibility.


OK, but what is the actual state of that compatibility?

https://github.com/w3c/webvr/issues/197#issuecomment-283492774 and 
https://github.com/w3c/webvr/issues/195#issuecomment-283493130 sure 
sound like at least Brandon is not on board with those parts of the 
current API, and he's one of the spec editors.



We have regularly scheduled video calls and F2F meetings to improve the spec 
and remove any ambiguity.  We have formed a W3C community working group.


That's good.  The question that bothers me is how this interacts with 
the ship schedule.



[1]  For example, what does the VRFrameData constructor actually do? The spec 
doesn't define it at all.  Where is the VRPose inside supposed to come from?  
What values will it contain?  I filed https://github.com/w3c/webvr/issues/195 
on this, but note that I've spent all of about 5 minutes skimming the spec and 
ran into this.  I have _not_ done a careful read looking for possible interop 
problems...


VRFrameData is described as receiving the output of the VRDisplay.getFrameData 
function:


Yes, but that's totally unrelated to my question about what the 
_constructor_ does


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

Re: Intent to ship: WebVR on Windows in Release

[Boris Zbarsky]

On 3/2/17 1:52 PM, kearw...@kearwood.com wrote:

I tend to agree with Brandon on this particular issue


That's fine.  I agree with you and Brandon too. ;)  I'm just worried 
about possible interop problems more than anything else at the moment.



Would this issue block release of WebVR in Firefox 54?


To some extent this is a call people more familiar with how this API 
gets used and what interop issues can arise should make.


Note that per 
https://github.com/w3c/webvr/issues/128#issuecomment-283854007 the 
behavior of getFrameData is not interoperable between Edge and Firefox: 
we create new objects hanging off the VRFrameData each time, while they 
mutate all the existing stuff in-place.  This can lead to bugs like code 
that tries to optimize by grabbing a reference to one of the typed 
arrays and then calling getFrameData and assuming the array they are 
referencing is updated (if they test in Edge).  Or not updated and 
represents the previous frame (if they test in Firefox)...


Again, I only spent a few minutes looking at this spec.  What would be 
most helpful here is if someone went through it carefully looking for 
underpecified bits like this, then filed issues as needed and checked 
what browsers actually do in the underspecified cases.  Then we can 
decide whether whatever behavior differences we find are sufficient that 
there is high interop risk from shipping.


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

Re: Intent to ship: WebVR on Windows in Release

[Boris Zbarsky]

On 3/6/17 3:03 PM, kearw...@kearwood.com wrote:

The underlying VR API's expect this process to persist for the browser's 
lifespan and to have mutually-exclusive access to input from the headsets.  It 
seems that the GPU process is the best fit afaict.


In case it matters, the GPU process does not have "persist for the 
browser lifespan" as a goal.  In fact, the whole point of the GPU 
process is that driver crashes should take down the GPU process but not 
the browser.  We then restart the GPU process as needed.  On some 
hardware/software configurations, this is apparently not a rare occurrence.


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

Re: Heads up: archive.m.o is no longer updating tinderbox builds, AWSY is effectively dead

[Boris Zbarsky]

On 3/6/17 4:17 PM, Eric Rahm wrote:

I'm unaware of a bug for this decision, but https://archive.mozilla.org
stopped adding tinderbox builds back on January 18th.


I'm unaware of a discussion of this at all.  Why did this happen?

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

Re: Heads up: archive.m.o is no longer updating tinderbox builds, AWSY is effectively dead

[Boris Zbarsky]

On 3/6/17 4:29 PM, Kartikaya Gupta wrote:

It looks like it's just the Linux builds that are no longer there. I'm
guessing this has to do with them being on TaskCluster rather than
BuildBot.


That sounds like a TaskCluster bug we should just fix, then populate 
archive.mozilla.org with the missing bits.


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

Re: Heads up: archive.m.o is no longer updating tinderbox builds, AWSY is effectively dead

[Boris Zbarsky]

On 3/6/17 5:29 PM, Mike Hommey wrote:

You can get the builds through the taskcluster index.


Does that have the same lifetime guarantees as archive.mozilla.org?

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

Re: Sheriff Highlights and Summary in February 2017

[Boris Zbarsky]

On 3/7/17 6:23 AM, David Burns wrote:

   - Autoland 6%.(24 backouts out of 381 pushes)
   - Inbound 12% (30 backouts out of 251 pushes)


Were those full backouts or partial backouts?

That is, how are we counting a multi-bug push to inbound where one of 
the bugs gets backed out?  Note that such a thing probably doesn't 
happen on autoland.


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

Re: Project Stockwell (reducing intermittents) - March 2017 update

[Boris Zbarsky]

On 3/7/17 9:26 AM, jma...@mozilla.com wrote:

We find that we are fixing 35% of the bugs and disabling 23% of them.


Is there a credible plan for reenabling the ones we disable?

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

Re: Project Stockwell (reducing intermittents) - March 2017 update

[Boris Zbarsky]

On 3/7/17 1:33 PM, Honza Bambas wrote:

I presume that when a test is disabled a bug is filed


As far as I can tell, that's not the case...

If that were the case, that would be a good start, yes.

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

Re: Project Stockwell (reducing intermittents) - March 2017 update

[Boris Zbarsky]

On 3/7/17 11:10 AM, jma...@mozilla.com wrote:

Do you have suggestions for how to ensure we keep up with the disabled tests?


Things that pop to mind are having "reenable this test" bugs filed, and 
possibly trying to reenable every so often and seeing whether it's still 
intermittent


-Boris

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

Re: Is there a way to improve partial compilation times?

[Boris Zbarsky]

On 3/7/17 2:05 PM, Mike Conley wrote:

FWIW, the MOZ_MAKE_FLAGS bit can probably be removed, as I believe mach
will just choose the optimal number based on examining your processor cores.


Except mach's definition of "optimal" is "maybe optimize for compile 
throughput", not "optimize for doing anything else at all with your 
computer while compiling".


I had to manually set a lower -j value than it was picking, because it 
was impossible for me to load webpages (read: do reviews) or read emails 
while a build was running, due to mach spawning too many jobs.  :(


Now my builds are 1-2 minutes slower (read: 3-5%), but at least I can 
get something else done while they're running.


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

Re: Is there a way to improve partial compilation times?

[Boris Zbarsky]

On 3/7/17 4:25 PM, Chris Peterson wrote:

Can you just nice mach?


I seem to recall trying that and it not helping enough (on MacOS) with 
the default "use -j8 on a 4-core machine" behavior.  YMMV based on OS, 
ratio of RAM to cores, and whatnot.


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

Re: Please write good commit messages before asking for code review

[Boris Zbarsky]

On 3/9/17 2:46 PM, Ehsan Akhgari wrote:

Starting now, I'm going to try out a new practice
for a while: I'm going to first review the commit message of all patches,
and if I can't understand what the patch does by reading the commit message
before reading any of the code, I'll r- and ask for another version of the
patch.


I will be doing likewise.

I believe dbaron does this already.

I encourage others to do this too.

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

Re: Please write good commit messages before asking for code review

[Boris Zbarsky]

On 3/9/17 4:35 PM, Eric Rescorla wrote:

I'm in favor of good commit messages, but I would note that current m-c
convention really pushes against this, because people seem to feel that
commit messages should be one line.


They feel wrong, and we should tell them so.  ;)  The first line should 
include a brief summary of the change.  The rest of the commit message 
should explain details as needed.


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

Re: Please write good commit messages before asking for code review

[Boris Zbarsky]

On 3/9/17 5:53 PM, Ben Kelly wrote:

Right now our security bug process asks about the commit message and if it
"paints a target" on the patch.


It asks this:

  Do comments in the patch, the check-in comment, or tests included
  in the patch paint a bulls-eye on the security problem?

I always interpreted that to mean "does the commit message give clues 
about how to exploit the pre-patch state?".  So a commit message like 
"Make sure that SVG elements with a 'fill' attribute that are adopted 
into another document don't leave dangling pointers behind" would 
probably be a bad idea for a security bug


I don't think there's anything you can do in the commit message to not 
make it scream out "security bug" to anyone who's actually trying, if 
you include the bug# in there


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

Re: Tracking bug for removals after XPCOM extensions are no more?

[Boris Zbarsky]

On 3/13/17 9:17 AM, Nathan Froyd wrote:

We do not.  Bug 1299187 is related to such work, but that bug only
covers unexporting symbols that 3rd party software would access.  bz
has filed a few bugs for removing nsIDOM* methods that only existed
due to 3rd party compat concerns, but I don't think there's been
systematic evaluation of what's just dead weight now.


I suspect that pretty much all nsIDOM* stuff is effectively dead weight. 
 The only question is how much of it has internal consumers and how 
hard it is to move those consumers to the webidl APIs instead.


There's a bunch of "good first bug" fodder here, easily parallelized, etc.

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

Re: Intent to ship: IntersectionObserver API

[Boris Zbarsky]

On 3/15/17 1:30 AM, Tobias Schneider wrote:

As of March 14 I intend to turn the IntersectionObserver API on by default
on all platforms.


This is really exciting stuff!

Some questions (largely based on the intent to ship/implement templates, 
fwiw):


1)  Is there devtools support for this (e.g. to be able to see what 
intersection observers are registered where)?  If not, are there at 
least bugs tracking it?


2)  How stable is the spec?  Do we have any signals from IE or Safari on 
where they stand wrt it?  Are there plans to add web platform tests for 
this stuff, instead of our mochitest?  It would be good to have some 
idea of how actual interop with Chrome looks, and with a wpt we could 
check that pretty easily.


3)  Has there been a security review?  The reason I ask is that the 
definition at 
https://wicg.github.io/IntersectionObserver/#intersectionobserver-intersection-root 
means the intersection root can be in a different-origin document, and 
then there are operations that use it, so it would be good to carefully 
check for cross-origin information leaks.  Do we have good tests for the 
various cross-origin scenarios?  I do see some cross-origin testing in 
dom/base/test/test_intersectionobservers.html, which is good.


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

Re: Intent to ship: IntersectionObserver API

[Boris Zbarsky]

On 3/15/17 1:32 PM, Tobias Schneider wrote:

1) No there isn't any yet. Good idea to file a bug for it tho.


OK.  Please make sure this happens.


2.1) Its was quite a living spec over the time I implemented things, but
stuff seams to stabilize now.
https://bugzilla.mozilla.org/show_bug.cgi?id=1243846 is tracking bug for
spec changes that we haven't addressed yet.


Do we plan to address those before shipping?  The bug you linked to is 
marked "resolved fixed", but I assume you mean the unfixed bugs blocking it?



2.2) No signals from Safari that I know of. IE seems to have it implemented
in their preview (
https://developer.microsoft.com/en-us/microsoft-edge/platform/status/intersectionobserver/
).


Again, do we have indications of how interoperable that is with our 
implementation?



2.3) Platform tests are in the process of being upstreamed by Google (
https://github.com/w3c/web-platform-tests/pull/4384).


That seems to be in limbo for well over a month now.  jgraham just poked 
it in hopes of at least getting automated testing going so we find out 
whether Firefox passes the tests... but that will test release, afaik. 
Have you checked whether we pass these tests?



3) Yeah, we have some tests in place. But there wasn't an official security
review yet. Who to be the person best to talk to?


I wish it didn't take me an hour of trying and failing to answer this 
question.


Maybe try rbarnes and dveditz, and ask them to create some pages on
wiki.mozilla.org that would actually be findable and not explicitly 
marked out of date?  :(


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

Re: Tracking bug for removals after XPCOM extensions are no more?

[Boris Zbarsky]

On 3/15/17 3:26 PM, Botond Ballo wrote:

What will happen to WebExtension Experiments once these APIs start
being removed? My understanding is that WebExtension Experiments use
the same XPCOM APIs as XUL addons.


We shouldn't be removing APIs that have no alternative.

But I doubt a WebExtension experiment would use (as a concrete example) 
nsIJSON instead of JSON.parse/stringify.


And we can work on removing non-scriptable XPCOM APIs of various sorts 
(e.g. nsIDOM*), because obviously WebExtension Experiments (unlike 
binary add-ons) can't use them.


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

Re: Tracking bug for removals after XPCOM extensions are no more?

[Boris Zbarsky]

On 3/15/17 6:51 PM, Benjamin Smedberg wrote:

On Wed, Mar 15, 2017 at 4:24 PM, Boris Zbarsky  wrote:

We shouldn't be removing APIs that have no alternative.


As a blanket statement, I don't understand what this means.


As a blanket statement, it would depend on an implied "that have consumers".


I am thinking the exact opposite sentiment: after Firefox 57 when
Webextensions are the only extensions, if our product no longer needs some
functionality (and it's "API"), let's remove it.


The key here is evaluating "needs".


Do we disagree, or do I misunderstand?


I don't think we disagree.

-Boris

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

Re: Tracking bug for removals after XPCOM extensions are no more?

[Boris Zbarsky]

On 3/15/17 5:35 PM, Henri Sivonen wrote:

What's the current outlook on letting chrome JS read ArrayBuffers as
opposed to JS strings where the high 8 bits are zero and the low 8
bits are the byte values from XPCOM streams?


I see no reason not to allow that.  We'd just add this on 
nsIScriptableInputStream, I assume, so we don't have to modify every 
single stream impl


There are some issues around doing this sort of thing on mainthread and 
the resulting sync I/O in some cases, of course.  But I don't think 
they're any worse than with nsIConverterInputStream anyway.


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

Re: Will script implementations of nsIOutputStream be prohibited once XPCOM extensions are no more?

[Boris Zbarsky]

On 3/16/17 3:35 AM, Henri Sivonen wrote:

Do we need to keep caring about
https://bugzilla.mozilla.org/show_bug.cgi?id=170416 once XPCOM
extensions are no more?


A first glance, no.

We should try marking nsIOutputStream builtinclass on trunk right now. 
As far as I can tell, this should just work.


-Boris

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

Re: Tracking bug for removals after XPCOM extensions are no more?

[Boris Zbarsky]

On 3/13/17 11:36 AM, Steve Fink wrote:

There's a whitelist of "safe" things that we assume will never be
overridden. But now I can remove everything that treats nsISupports
specially.


Things can still be implemented in chrome JS via XPCWrappedJS, right?

Assuming the analysis will consider all known overrides of the relevant 
virtual method, we need to also restrict to cases in which the relevant 
class is builtinclass, I would think.


-Boris

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

Please do NOT hand-edit web platform test MANIFEST.json files

[Boris Zbarsky]

We have tools for this: "mach wpt-manifest-update" will do the right thing.

The typical result of hand-edits is that later changesets that do use 
the tools end up conflicting with each other, as they all fix up the 
incorrect hand-edits.  Please don't cause this pain for other developers 
and the sheriffs.


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

Re: windows build anti-virus exclusion list?

[Boris Zbarsky]

On 3/17/17 3:40 PM, Ted Mielczarek wrote:

We do try to build js/src pretty early in the build


We do?  It's always the last thing I see building before we link libxul. 
 Seeing the js/src stuff appearing is how I know my build is about done...


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

Re: Posthumous intent to unship: experimental createImageBitmap() overload accepting ArrayBuffer and ArrayBufferView arguments

[Boris Zbarsky]

On 3/18/17 2:09 AM, Anne van Kesteren wrote:

I'm not sure this should be unusual though.


The unusual thing is unshipping an API that has shipped in release, via 
direct landing on release, without any sort of deprecation period, going 
through nightly/aurora/beta, etc.


This should in fact be unusual!


The standard wasn't
updated to include this functionality. We shouldn't ship new
web-exposed APIs without at least some discussion and a draft of what
we're intending to ship as a minimum.


Sure.  This should not have been shipped (and the fact that it was 
shipped was an accident: one of the changesets in the bug implementing 
it did not get checked in, and that was the changeset which disabled the 
API on release if the right pref was not set).  Not shipping things that 
are not ready shouldn't be unusual, we all agree.  ;)


-Boris

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

Re: Please do NOT hand-edit web platform test MANIFEST.json files

[Boris Zbarsky]

On 3/19/17 12:36 AM, Nils Ohlmeier wrote:

Wouldn’t it make more sense to let the build system detect and reject/warn 
about (?) such a manual modification?


That would be ideal, but there are some issues with doing it.  We tried 
adding a lint, but it was orange _all the time_ because the sanest 
possible workflow of "edit a test file" or "add a test file using the 
mach command we have for it" looked like manual modification.


We're working on a better setup for this, but in the meantime it would 
be good if people would try to use the tools we have to make life a bit 
less painful.


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

Preferences::RegisterCallback and variants will now do exact, not prefix, matches

[Boris Zbarsky]

I have just landed a change[1] which changes 
Preferences::RegisterCallback/RegisterCallbackAndCall to do an exact, 
not prefix, match on the passed-in string.


So if you do:

  Preferences::RegisterCallback(MyFunc, "foo");

and the preference named "foobar" changes, MyFunc will no longer be 
called.  Most consumers did not expect this behavior, and a number were 
buggy as a result.


The old behavior is still available via a new 
RegisterPrefixCallback/RegisterPrefixCallbackAndCall/UnregisterPrefixCallback 
API.  These can be used to observe all preferences whose names start 
with the given string.


One caveat: It's very important to correctly pair up the registration 
and unregistration functions.  If you RegisterPrefixCallback but then 
UnregisterCallback, it will not actually unregister the callback.


-Boris

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1348331
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please do NOT hand-edit web platform test MANIFEST.json files

[Boris Zbarsky]

On 3/21/17 6:41 PM, Jeff Gilbert wrote:

JSON allows comments if all the JSON processors we use handle comments. :)


JSON.parse in JS does not.

The Python "json" module does not as far as I can tell.

What JSON processors are you thinking of?

-Boris

P.S.  The Python "json" module is most relevant here, since it's the 
thing actually being used to deal with MANIFEST.json.

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

Re: Preferences::RegisterCallback and variants will now do exact, not prefix, matches

[Boris Zbarsky]

On 3/21/17 4:34 PM, Eric Rahm wrote:

This doesn't affect the behavior of |Preferences::AddStrongObserver| which
does prefix matching, correct?


That's correct.  Same for AddWeakObserver.

It's a little harder to misuse because it doesn't have a closure arg (so 
you can't just associate the totally wrong value with the closure in 
some way, which was the main failure mode for RegisterCallback).


But just for fun, start a debug build, open "about:config", create a new 
preference called "intl.accept_languages_are_confusing" with any value 
you want, and watch the nice MOZ_ASSERT failure in 
nsGlobalWindow::Observe on this line:


MOZ_ASSERT(!NS_strcmp(aData, u"intl.accept_languages"));

So maybe we should push the exact/prefix match business down into the 
pref observer API.  :(


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

Re: Preferences::RegisterCallback and variants will now do exact, not prefix, matches

[Boris Zbarsky]

On 3/21/17 7:18 PM, zbranie...@mozilla.com wrote:

Is there a reason we should use RegisterCallback over AddStrongObserver?


It doesn't require creating a separate object to act as an observer.  Of 
course it creates one under the hood for you, so this is mostly a matter 
of whether calling code ends up simpler or not, not of efficiency.



I have a fresh API where I'm using AddStrongObserver at the moment, but would 
be happy to switch if that will be cheaper / more future-compatible.


Are you properly handling the fact that AddStrongObserver watches all 
prefs starting with the prefix you pass it?  ;)


-Boris

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

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

[Boris Zbarsky]

On 3/22/17 2:38 PM, Mats Palmgren wrote:

Does that sound reasonable?


Yes, thank you!

-Boris

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

Re: Preferences::RegisterCallback and variants will now do exact, not prefix, matches

[Boris Zbarsky]

On 3/22/17 6:17 PM, zbranie...@mozilla.com wrote:

On Tuesday, March 21, 2017 at 7:46:07 PM UTC-7, Boris Zbarsky wrote:

Are you properly handling the fact that AddStrongObserver watches all
prefs starting with the prefix you pass it?  ;)


I don't, and I'd love not to. I know perfectly well this two strings I want to 
watch only them.


Well, AddStrongObserver will only do prefix checking for you.  Anything 
else you have to do yourself at the moment


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

Re: Please do NOT hand-edit web platform test MANIFEST.json files

[Boris Zbarsky]

On 3/22/17 8:11 PM, gsquel...@mozilla.com wrote:

(Is the ~10s extra build time unacceptable?)


I just checked on my local machine, and a full manifest update takes 
over a minute.  I rather doubt your machine is actually 6x faster than 
mine, so I have to assume that you didn't actually time a full manifest 
update.


-Boris

P.S.  My 1-minute time is consistent with the times we were seeing 
before James added the checked-in hashes, which is why he added them.

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

Re: Intent to unship: :-moz-bound-element pseudo-class.

[Boris Zbarsky]

On 3/25/17 2:06 PM, Emilio Cobos Álvarez wrote:

I don't think there's any benefit of keeping untested and unused stuff
in the tree, but if I got it wrong, or anyone has any concern, please
speak.


Removing this makes sense to me.

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

Web IDL review checklist updated

[Boris Zbarsky]

I just updated https://wiki.mozilla.org/WebAPI/WebIDL_Review_Checklist 
to remove some no-longer relevant bits and add various new parts.


The primary audience for this document are people doing Web IDL reviews 
(bcced; you can see the list at 
), 
but obviously anyone _requesting_ such review should consider running 
through the list before doing so.


Suggestions for further additions (or just edits of the page!) are much 
appreciated.


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

Re: Web IDL review checklist updated

[Boris Zbarsky]

On 4/3/17 3:53 PM, Kyle Huey wrote:

There should probably be something about checking that the spec is
something other vendors are interested in, or that Mozilla has a good
reason to go ahead without them.


Ah, good point.  I added a thing about ensuring that an intent to 
implement is sent, and that the reviewer would not be objecting to said 
intent in the first place.


-Boris

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

Re: Intent to change editor newline behavior

[Boris Zbarsky]

On 4/5/17 10:14 AM, Aryeh Gregor wrote:

On Wed, Apr 5, 2017 at 4:48 PM, Ehsan Akhgari  wrote:

But to me it seems like the kind of thing that we'd
want to be able to quickly turn off on the release channel through
shipping a hotfix add-on that sets a pref if something goes wrong...


FWIW, changing the default back to  is a one-line change already.


The difference is that a hotfix addon does not involve people restarting 
their browser to pick up an update, don't involve creating a new 
release, etc, etc.


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

A reminder about commit messages: they should be useful

[Boris Zbarsky]

A quick reminder to patch authors and reviewers.

Changesets should have commit messages.  The commit message should 
describe not just the "what" of the change but also the "why".  This is 
especially true in cases when the "what" is obvious from the diff 
anyway; for larger changes it makes sense to have a summary of the 
"what" in the commit message.


As a specific example, if your diff is a one-line change that changes a 
method call argument from "true" to "false", having a commit message 
that says "change argument to mymethod from true to false" is not very 
helpful at all.  A good commit message in this situation will at least 
mention the meaning for the argument.  If that does not make it clear 
why the change is being made, the commit message should explain the "why".


Thank you,
Boris

P.S.  Yes, this was prompted by a specific changeset I saw.  This 
changeset had been marked r+, which means neither the patch author not 
the reviewer really thought about this problem.

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

Re: A reminder about commit messages: they should be useful

[Boris Zbarsky]

On 4/17/17 10:45 PM, Jim Blandy wrote:

It seems like there is actually not a consensus on this. (I had thought
Smaug's view was the consensus, and found bz's post surprising.)


Really?  I know where Olli is coming from, but even in his view a commit 
message like the one I was talking about is not OK, I'm pretty sure.


And note that in this case the bug had no useful information either, for 
what it's worth.


But for the record, I disagree with Olli, precisely because of long and 
hence unreadable bugs.  If your commit message _can_ reasonably distill 
a long bug discussion, then I think it should.



If this is worth settling


For what it's worth, I don't think we need the "should the commit 
message describe all the context?" discussion settled just to settle the 
question of whether the commit message should _add_ anything to the 
commit other than the bug number.  Especially when the bug doesn't 
explain the purpose of the commit either!


For the overall question here, I agree that we're not going to get 
anywhere in a mailing list discussion.  ;)


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

Re: A reminder about commit messages: they should be useful

[Boris Zbarsky]

On 4/18/17 3:00 AM, Anne van Kesteren wrote:

On Mon, Apr 17, 2017 at 5:16 PM, Boris Zbarsky  wrote:

A quick reminder to patch authors and reviewers.


Is this documented somewhere so you can just point folks to
documentation if they get it wrong?


Not yet.  As this thread shows, there's some lively disagreement on what 
such documentation should say... :(


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

Re: A reminder about commit messages: they should be useful

[Boris Zbarsky]

On 4/25/17 10:50 AM, Alexander Surkov wrote:

I don't want to affirm that this approach suites every Mozilla module, but it 
seems be working well in relatively small modules like accessibility one.


Just as a counterpoint... as non-regular contributor to the 
accessibility module, I have a _very_ hard time making sense of 
accessibility commits, precisely because the commit messages are not 
often not very descriptive and the bugs are often hard to make sense of 
for a non-expert.


I don't have this problem in cases where I'm similarly out of my depth 
but commit messages contain more information.


-Boris

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

Re: A reminder about commit messages: they should be useful

[Boris Zbarsky]

On 4/25/17 1:07 PM, Alexander Surkov wrote:

I bet there's always room for improvements, and I hope this was a counterpoint 
for the example only, not for the bug organization approach.


Sort of.

It was a counterpoint to "just check the bug; all the info is there". 
Often it's not there, or not there in usable form.


If people included a summary of the discussion in the bug right about 
when they commit, or had bugs that actually explained what's going on 
clearly. I would be a lot more OK with the "check the bug" approach.



Overall it feels with me that long comments vs check-the-bug is rather 
different styles


To be clear, I don't think commit messages need to be _long_.  They need 
to be _useful_.  A commit message pointing to a particular bug comment 
that explains all the ins and outs is no worse, from my point of view, 
than a commit message that explains the ins and outs.


The problem I started this thread to address is things like a commit 
message that says "flip this bit" and references a bug entitled "flip 
this bit", with no explanation of what the bit does or why it should be 
flipped.  I hope we can all agree that _that_ is not OK.  And it's far 
too common.


-Boris

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

Re: A reminder about commit messages: they should be useful

[Boris Zbarsky]

On 4/25/17 4:27 PM, Alexander Surkov wrote:

Maybe we should have a style guide, explaining what makes a good commit message 
and what makes a good and descriptive bug, with number of (good and bad) 
examples.


Yes, we should.

Maybe we should have a discussion at the all hands about this...

-Boris

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

Re: Editing vendored crates take #2

[Boris Zbarsky]

On 4/28/17 1:05 PM, Josh Matthews wrote:

Has anybody been able to make this work?


I _think_ I made it work recently-ish, like so:

1)  Modify toolkit/library/rust/Cargo.toml with the relevant [replace] bit.

2)  Run "cargo vendor" and watch it fail because of something I never 
figured out.


3)  revert the changes "cargo vendor" made to third-party/rust (i.e. 
deleting the whole dir)


As it happens, "cargo vendor" updated the Cargo.lock files in the right 
way before it failed out, so things worked.  Again, I _think_ that was 
the procedure.


I'm not claiming this is in any way sane, btw.

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

Re: Editing vendored crates take #2

[Boris Zbarsky]

On 5/2/17 2:54 PM, Josh Matthews wrote:

My cargo from April 19 claims that "cargo vendor" isn't a real command.
Did you mean `./mach vendor rust`


Er, yes, I did.

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

Re: Representing a pointer to static in XPConnected JS?

[Boris Zbarsky]

On 5/5/17 4:09 AM, Henri Sivonen wrote:

On Thu, May 4, 2017 at 7:39 PM, Nathan Froyd  wrote:

I think you could possibly make your things a WebIDL interface, which
don't require refcounting, and magically make the WebIDL interfaces
work with XPIDL, but I do not know the details there.


I'll keep that in mind. Thanks.


I'm not sure this is going to work in this case.  WebIDL interfaces that 
don't require refcounting basically require that the JS object owns the 
C++ thing; it will delete it when finalized.


You could do non-virtual no-op refcounting.  But you still have a 
problem where ToJSValue only knows how to work with subclasses of either 
nsISupports or nsWrapperCache, both of which involve virtual functions.


If I can take a step back, though, you have the following requirements:

1)  The same Encoding* has to lead to the same JS object.  This means 
you need either a global or a per-compartment (depending on how your 
object behaves in terms of cross-compartment wrappers) mapping from 
Encoding* to JS object.  We have automated machinery for both versions 
of that, but it depends on either nsWrapperCache (for the global 
mapping) or nsISupports (pretty sure on that) for the cross-compartment 
mapping.  We would have to add extra machinery of one sort of the other 
to handle not inheriting from either one.


2)  The JS representation needs to be an object.  This is probably good 
in terms of typesafety (in that we can check whether the object is 
actually the thing we were passed), but complicates the other bits.  For 
example, if this were not a requirement, we could conceivably use a JS 
PrivateValue to just directly encode the Encoding* in a value that looks 
like a JS Number.  This does mean that on JS-to-C++ conversion we'd 
effectively reinterpret_cast a double to an Encoding*, so if someone 
messed up and passed some random double bad things would happen.


One thing that is not clear to me: do you need support for this on 
worker threads, or just mainthread?  Because if this is not needed on 
workers, one thing we _could_ conceivably do is have some sort of setup 
where we define a new type that looks like void* on the C++ side and a 
JS object on the JS side, allocate the objects in the privileged junk 
scope, give them a recognizable JSClass to typesafety and a PrivateValue 
reserved slot for JS-to-C++ mapping, have a xpconnect-wide hashtable for 
C++-to-JS mapping.  We could either have a finalizer that removes from 
the xpconnect-wide hashtable or trace that hashtable and thereby keep 
the objects alive forever or whatever; that mostly depends on how you 
want them to behave as weakmap keys.


This would be a bit of work, but not too insane, I think.

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

Re: Representing a pointer to static in XPConnected JS?

[Boris Zbarsky]

On 5/5/17 2:57 PM, Henri Sivonen wrote:

I'm not sure what chrome JS runs on non-main threads and if there's
non-main-thread chrome JS doing things like obtain an encoding name
from a channel and pass it to the UTF8 converter service.


There's nothing like that going on.


This seems complicated enough that it's probably the best to have
non-scriptable methods that are type-safe for C++ usage and scriptable
overloads that deal with encoding names as strings for chrome JS.
After all, Web Platform JS represents encodings as strings, too.


OK.  This does seem like the path of least resistance for the moment...

-Boris

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

Re: Using references vs. pointers in C++ code

[Boris Zbarsky]

On 5/9/17 9:17 AM, Nathan Froyd wrote:

On Tue, May 9, 2017 at 5:58 AM, Emilio Cobos Álvarez  wrote:

Personally, I don't think that the fact that they're not used as much as
they could/should is a good argument to prevent their usage, but I don't
know what's the general opinion on that.


The argument I have always heard, Gecko-wise and elsewhere [1], is to
prefer pointers for modification


This is for primitive-typed out or inout params, right?

In other words, we should prefer "int*" to "int&" for places where we 
expect the callee to modify the int, just like we should prefer 
"MyClass**" to "MyClass*&".  I guess the same for POD structs if we 
expect people to be writing to them wholesale via assignment operators? 
Not sure.


But for object-typed things like dom::Element or nsIFrame, it seems 
better to me to pass references instead of pointers (i.e "Element&" vs 
"Element*") for what are fundamentally in params, even though the callee 
may call mutators on the passed-in object.  That is, the internal state 
of the element may change, but its identity will not.


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

Re: Using references vs. pointers in C++ code

[Boris Zbarsky]

On 5/9/17 9:03 AM, Bobby Holley wrote:

I think passing non-nullable things by reference is good, but I think we
should keep it consistent for a given type.


I should note that we already have this across all types to some extent: 
WebIDL bindings pass non-nullable interface types as references, on 
purpose, to make it clear that they can't be null (and conversely to 
make it very clear which things _can_ be null and hence need null-checking).


In case it's not obvious, I support passing non-nullable things as 
references.  ;)


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

Re: Using references vs. pointers in C++ code

[Boris Zbarsky]

On 5/9/17 11:41 AM, Nathan Froyd wrote:

I think I would feel a little
better about this rule if we permitted it only for types that deleted
assignment operators.  Not sure if that's really practical to enforce.


Hmm.  I wonder what happens right now if you try to invoke 
nsINode::operator=


But yes, having such a restriction would make sense to me if we can do it.

-Boris

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

Re: Intent to Ship throttling of tracking timeouts

[Boris Zbarsky]

On 5/11/17 10:59 AM, Andreas Farre wrote:

As of 2017-05-15 I intend to turn on throttling of background tracking
timeouts by default.


For purposes of this feature, what is the definition of "tracking timeout"?

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

Re: Intent to Ship throttling of tracking timeouts

[Boris Zbarsky]

On 5/11/17 10:30 PM, Eric Shepherd (Sheppy) wrote:

So part of private browsing and not a developer-facing feature, then?


No, as I understand this is being applied across the board, not just in 
private browsing, and not just if tracking protection is generally enabled.


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

Re: Intent to ship: SourceMap header

[Boris Zbarsky]

On 5/17/17 11:01 AM, Tom Tromey wrote:

In this case I think this does not apply, because as far as I'm aware
source maps are not part of any standard process; rather there is:

https://github.com/source-map/source-map-rfc


Are there any plans to have a standard here?  It really would be good to 
have all UAs converge on a single format here, both for the header and 
for the sourcemap itself, especially if we're going to have an 
unprefixed name for the header...  Speaking of which, is there a plan to 
register this header with IANA (see 
)?


Is there any web-page-observable behavior change from sourcemaps (e.g. 
.stack on exceptions?), or is it all about how devtools behave?


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

Re: Avoiding jank in async functions/promises?

[Boris Zbarsky]

On 5/17/17 9:22 PM, Mark Hammond wrote:

I'm wondering if there are any ideas about how to solve this optimally?


I assume 
https://w3c.github.io/requestidlecallback/#the-requestidlecallback-method 
doesn't have quite the right semantics here?  That would let you run 
when the browser is idle, and give you some idea of how long you can run 
for before you should yield.


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

Re: Intent to unship: -moz-placeholder pseudo-element and pseudo-class

[Boris Zbarsky]

On 5/24/17 1:06 PM, Mike Taylor wrote:

[1]



Sadly, that code is already buggy in Firefox: it uses 
":moz-placeholder", which doesn't parse.  The thing that parses is 
":-moz-placeholder".


-Boris

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

Re: Intent to ship: SourceMap header

[Boris Zbarsky]

On 5/17/17 2:14 PM, Nick Fitzgerald wrote:

In my experience, trying to get anyone to comment or provide feedback on
source map RFCs was a huge pain, and it felt to me like nobody (other
browser devtools teams, maintainers of compilers targeting JS) cared enough
about source maps to get involved or contribute.


OK, but can we at least make sure the browser devtools teams and 
compilers targeting JS are all on the same page with respect to this 
stuff?  Do we know whether they are or not?  This was not indicated in 
the initial intent in any way.



* Clean up the spec text and any ambiguities it may have; make it a
"proper" standard


I think this would be a good thing to do anyway.  Otherwise we're likely 
to end up needing to reverse-engineer other browsers around this stuff.


Specifically, we should have a spec for the sourcemap header, and 
separately we should have a spec for the sourcemap itself.


And we should actually register the header.


* Pull a wasm on the source map format: create an isomorphic, but much more
compact binary format
* Add the ability to encode source level scopes, bindings, and a way to
recover bindings' values


Those sound good, as part of the spec work...

-Boris

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

Re: Improving visibility of compiler warnings

[Boris Zbarsky]

On 5/25/17 8:31 AM, Ehsan Akhgari wrote:

This currently only
serves to make it more difficult to find compiler errors when they
occur.


Fwiw (and not to distract from your main point), 
https://bugzilla.mozilla.org/show_bug.cgi?id=1367405 just got fixed so 
we should no longer get the warning spew when there are compiler errors.


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

Re: Linux builds now default to -O2 instead of -Os

[Boris Zbarsky]

On 6/1/17 9:04 PM, Mike Hommey wrote:

Ah, forgot to mention that. No, it doesn't affect *our* shipped builds
(because PGO uses a different set of optimization flags).

But it does affect downstream builds that don't PGO.


Based on the jump I see on June 2 at 
https://treeherder.mozilla.org/perf.html#/graphs?timerange=2592000&series=%5Bmozilla-central,80984697abf1f1ff2b058e2d9f0b351fd9d12ad9,1,1%5D&series=%5Bmozilla-central,ae68c64ef8bfa104fded89971f1c2c6c90926dca,1,1%5D&series=%5Bmozilla-central,dd55da63ebce86ee3867aa3b39975c2a90869ce2,1,1%5D 
it affects some of our talos tests too (the ones running on non-pgo).


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

Re: JSBC: JavaScript Start-up Bytecode Cache

[Boris Zbarsky]

On 6/13/17 11:00 AM, Dirkjan Ochtman wrote:

Has anyone thought about doing similar things for chrome JS?


We've been doing fastload for chrome JS (and indeed for entire chrome 
XUL documents, including their scripts) for 15+ years now, no?


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

Re: JSBC: JavaScript Start-up Bytecode Cache

[Boris Zbarsky]

On 6/13/17 5:23 PM, Kris Maglione wrote:

Yes and no. We do something similar to this for the module loader and
subscript loader, but only for the entire compiled source, not for
individual functions, and without any kind of lazy compilation.


True.


For 

Re: Changing .idl files

[Boris Zbarsky]

On 6/14/17 12:23 PM, Andrew Swan wrote:

I would hope that if we have promising or widely used webextension
experiments, that the relevant peers would be aware of them when reviewing
changes that might affect them


I don't see how they would be, unless we have something like dxr for the 
relevant code.


As a concrete example, how would a necko peer know that some 
webextension experiment uses or doesn't use various necko interfaces?


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

Re: Overhead of returning a string from C++ to JS over WebIDL bindings

[Boris Zbarsky]

On 6/16/17 7:22 AM, Henri Sivonen wrote:

My hypothesis is that the JSC/WebKit overhead of returning a string
from C++ to JS is much lower than SpiderMonkey/Gecko overhead or the
V8/Blink overhead.


It definitely is.  JSC and WebKit use the same exact refcounted strings, 
last I checked, so returning a string from WebKit to JSC involves a 
single non-atomic refcount increment.  It's super-fast.


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

Re: Profiling nightlies on Mac - what tools are used?

[Boris Zbarsky]

On 6/19/17 6:03 PM, Chris Cooper wrote:

If you profile on Mac, now is your chance to speak up. What other profiling 
tools do you use that we should be aware of?


Instruments for targeted profiling, though I mostly do that on my own 
builds, not mozilla.org nightlies.  The sampling tool in Activity 
Monitor for opportunistic "my browser just hung" profiling of my nightly.


The Gecko profiler doesn't work for the "my browser just hung" case, 
obviously, and is so far a much worse user experience than Instruments 
for normal profiling.  I end up using it mostly for "something was just 
slow, what was it?" profiling, mostly.


The other thing stripping would affect is debugging.  And yes, I've had 
to attach a debugger to a nightly a few times to figure out something 
when I ran into a problem while browsing.  The symbols we have are not 
great for debugging, but they're a lot better than nothing.


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

Re: Profiling nightlies on Mac - what tools are used?

[Boris Zbarsky]

On 6/19/17 11:22 PM, Gregory Szorc wrote:

The decision to strip Nightly builds does not come lightly. Read 1338651
comment 111 and later for the ugly backstory.


It's still really confusing to me that not stripping symbols has a 
significant performance impact.  That's not the case in any other build 
configuration I'm aware of, and is somewhat surprising from first 
principles for everything except startup performance.


It really would be good to figure out what's actually going on there...

-Boris

P.S.  Yes, I'd like to have my symbols cake and eat my performance cake 
too.  ;)

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

Re: Getting a JS stack from an automation assertion

[Boris Zbarsky]

On 6/20/17 1:53 PM, Benjamin Smedberg wrote:

Is there a way to have automation call DumpJSStack() on assertion (before
crashing)


You could hack a DumpJSStack() call into the nsDebug machinery, basically.


Would it be safe to call DumpJSStack() explicitly from the place where I'm
firing this assertion, or are there potential issues with locking or the JS
engine internals that would make this a bad idea? (And would that output
show up in the automation logs?)


Calling DumpJSStack is generally safe, I believe, as long as you know 
that you're on the main thread or a DOM worker thread.  It'll crash on 
you on other threads.


Given that you're dealing with shutdown, you need to make sue your call 
happens before nsContentUtils::Shutdown, but hopefully that's the case 
anyway if you know you're running JS.


One possible failure mode of DumpJSStack is that it will print nothing 
if we're conceptually not running JS (e.g. have an AutoNoJSAPI on the 
stack).  You could work around that if you end up hitting it by 
replacing the nsContentUtils::GetCurrentJSContextForThread() call in 
xpc_DumpJSStack with mozilla::dom::danger::GetJSContext.


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

Re: Profiling nightlies on Mac - what tools are used?

[Boris Zbarsky]

On 6/21/17 10:44 AM, Ehsan Akhgari wrote:

It seems like that we have an answer now in the bug!
https://bugzilla.mozilla.org/show_bug.cgi?id=1338651#c129


Just for clarity, so people don't have to read the whole bug, changing 
the _path_ the build is at when it's compiled/linked results in the huge 
observed performance difference.  At least if I understand the comments 
in the bug correctly.


-Boris

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

Re: switch to macosx cross-compiled builds on taskcluster on trunk

[Boris Zbarsky]

On 6/21/17 2:38 PM, Kim Moir wrote:

At 11:00PT today, we will be landing patches to run mac opt builds on trunk
as cross compiled builds on Linux machines on taskcluster.


I just wanted to thank everyone who has worked on this change.  I know 
there were a bunch of nasty obstacles to making this happen, and a ton 
of work by many people went into it.  This change is awesome, both in 
terms of allowing us to better scale our Mac build infrastructure and in 
terms of allowing us to build/ship Stylo on Mac.


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

Re: Overhead of returning a string from C++ to JS over WebIDL bindings

[Boris Zbarsky]

On 6/22/17 4:43 AM, Henri Sivonen wrote:

The length of the string is always well over 100, so that already
means that a string cache isn't interfering with the test, right?


The way the string cache works is that it will reuse an existing 
JSString* in two situations:


1)  The nsStringBuffer* is the same exact pointer as the cached thing.
2)  The nsStringBuffer* is different, but length < 100 and the chars
match the cached thing.

In your case, situation 2 is not applying; presumably situation 1 is not 
either, so you create a new JSString.  I think Jan is suggesting that 
you could make situation 2 apply by raising that "100" limit.  Whether 
the resulting compare is faster than allocating JSString and GC is not 
obvious, of course.



Jan said "We create external strings (a JS string referencing a DOM
string buffer) for the strings returned from DOM to JS", so that means
Gecko does roughly the same in this case, right?


With a bunch more overhead (atomic refcounts, function calls, etc), but yes.


Could it be that JSC
realizes that nothing holds onto the string and derefs it right away
without having to wait for an actual GC?


Possible.  I haven't looked at their code in a while.

-Boris


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

Re: Overhead of returning a string from C++ to JS over WebIDL bindings

[Boris Zbarsky]

On 6/22/17 6:19 AM, Henri Sivonen wrote:

https://hsivonen.com/test/moz/encoding_bench_web/english-only.html


OK, so here's what I'm seeing on that benchmark, all numbers measured on 
Mac with a current nightly; other platforms may differ, etc.  Profile at 
https://perf-html.io/public/f6a0a4a61edcd784b461d17ea3879c30e03ee7fb/calltree/?implementation=cpp&thread=2 
for someone who wants to look themselves, but the numbers below are from 
an Instruments profile, because there I can do a much saner job of 
coalescing the various codepaths that lead to the functions of 
interest... [1]


Out of a total time of 7.6s or so on the main thread, 5.4s is under 
TextDecoderBinding::decode.  2.1s is under gcIfRequested.  The remaining 
time, what there is of it, is almost all under various JS execution bits.


The time under gcIfRequested is almost all under sweeping/finalization. 
In fact, it's almost all under arena deallocation.  I see 1.7s under 
huge_dalloc/chunk_dealloc (on Mac), with most of that (1.4s) being the 
madvise calls we make there and another 0.3s calling munmap.  Depending 
on what it is we're freeing (the GC arenas themselves or the string 
data), either nursery allocation for external strings[2] or background 
finalization of external strings[3] would help here.  The stacks look 
like we're freeing gc arenas, but it seems like there would be more 
freeing of the string data...


The time under TextDecoderBinding::decode is almost all (5.34s out of 
5.4s) under encoding_rs::Decoder::decode_to_utf16 and in particular in 
encoding_rs::variant::VariantDecoder::decode_to_utf16_raw.  That's all 
self time in there.  I do see numbers that are much slower than Safari 
here, for what it's worth (about 2x), and the 25% of our time spent 
under gc is not nearly enough to account for the difference.


-Boris

[1] Not least because of 
https://github.com/devtools-html/perf.html/issues/388

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1375565
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=627220

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

Re: Sheriff Survey Results

[Boris Zbarsky]

On 6/23/17 8:39 AM, Carsten Book wrote:

We got a lot of Feedback thats its not easy to find out who is on
"sheriffduty". We will take steps (like adding |sheriffduty tag to irc
names etc)


For what it's worth, searching IRC names is a bit of a pain.  Can we 
just throw the current sheriff nick in the topic of #developers or some 
other channel?


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

Re: Converting const char (&name)[N] to nsACString

[Boris Zbarsky]

On 7/5/17 5:41 AM, nmago wrote:

char* cname = new char[N];
memcpy(cname, &name, N);
nsACString strName(cname, N, 0);


This copies the data twice, and leaks it once, as far as I can tell.

What, exactly, are you trying to accomplish?  For example, do you need 
an nsACString that has a copy of your data or just points into it 
temporarily?


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

Re: Phabricator Update, July 2017

[Boris Zbarsky]

On 7/12/17 11:54 AM, Byron Jones wrote:

or uploading patches directly to bugzilla.


But still rewriting existing links (including from the mirrored review 
comment comments, so it's clear which diff the review comments applied 
to), right?


-Boris


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

Re: Phabricator Update, July 2017

[Boris Zbarsky]

On 7/13/17 9:04 PM, Mark Côté wrote:

It is also what newer systems
do today (e.g. GitHub and the full Phabricator suite)


I should note that with GitHub what this means is that you get 
discussion on the PR that should have gone in the issue, with the result 
that people following the issue don't see half the relevant discussion. 
In particular, it's common to go off from "reviewing this line of code" 
to "raising questions about what the desired behavior is", which is 
squarely back in issue-land, not code-review land.


Unfortunately, I don't know how to solve that problem without 
designating a "central point where all discussion happens" and ensuring 
that anything outside it is mirrored there...


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

Re: Phabricator Update, July 2017

[Boris Zbarsky]

On 7/14/17 1:31 AM, Jim Blandy wrote:

But keeping all the comments in one thread is a mixed blessing, too


Absolutely.

I guess what I'm saying is we should try to have some guidelines for 
when it's appropriate to take the discussion back to the bug instead of 
continuing it in the review...


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

Intent to implement and ship: SVGImageElement as CanvasImageSource

[Boris Zbarsky]

Summary: allow passing  to canvas createPattern and drawImage.

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

Spec: 
https://html.spec.whatwg.org/multipage/canvas.html#htmlorsvgimageelement 
and https://html.spec.whatwg.org/multipage/canvas.html#canvasimagesource


Platform coverage: all

Target release: 56

Preference: None.

Support in other engines: Chrome is adding support; see 
. 
 I don't know about Safari or Edge.


Tests: Still figuring this out.  If there aren't any, I'll add some.

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

Re: Intent to implement and ship: SVGImageElement as CanvasImageSource

[Boris Zbarsky]

On 7/18/17 11:21 PM, Tom Ritter wrote:

This will respect the 'svg.in-content.enabled' pref, correct?


Respect in what sense?

What this will do is that _if_ you have an  and you drawImage 
it to a canvas, that will work, assuming the  was loaded.


I don't think the pref you mention prevents such loading (or has any 
other effects that I can see), fwiw...


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

Re: Intent to implement and ship: SVGImageElement as CanvasImageSource

[Boris Zbarsky]

On 7/18/17 11:56 PM, Tom Ritter wrote:

Sorry I got the pref name wrong; it's svg.disabled from
https://bugzilla.mozilla.org/show_bug.cgi?id=1216893


Ah.

So as you note, this pref, when set, makes it so you can't even create 
an SVGImageElement instance.  And then of course you can't pass one to 
drawImage, since you don't have it to start with.


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

Re: Converting const char (&name)[N] to nsACString

[Boris Zbarsky]

On 7/21/17 9:44 AM, nmago wrote:

Yes, I needed nsACString copy of data to use it as nsACString argument for 
other function.


Assuming "cname" is a char[N] or char*, you should be able to do:

  nsCString str(cname, N);

This will make a copy of the first N bytes of cname and add a 
null-terminator.  No need for allocation, manual memcpy, anything like that.


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

Re: who uses idl stuff

[Boris Zbarsky]

On 7/23/17 9:58 PM, Enrico Weigelt, metux IT consult wrote:

what's the difference between idl and webidl ?


Brief summary.  IDL:

1)  Generates xptcall information for xpconnect to allow calling from JS 
and into JS (via synthetic vtables).

2)  Generates headers that declare pure virtuals.
3)  Is used for defining XPCOM interfaces.

(you can do just #2 without #1 if the interface is not scriptable).

WebIDL:

1)  Generates C++ glue code to allow calling from JS (or into JS in the 
case of callbacks or callback interfaces).
2)  Is used for defining things that are part of the web platform.  Is 
standardized at https://heycam.github.io/webidl/



I've noticed that webidl's seem to support preprocessor directives
(eg. #ifdef), while the others dont.


That is one of the many differences, yes.  They also have different use 
cases, different syntax, different output.


-Boris

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

Re: Actually-Infallible Fallible Allocations

[Boris Zbarsky]

On 8/2/17 11:18 AM, Nathan Froyd wrote:

In particular, the API of Sequence<> is constrained because it
inherits from FallibleTArray, which *only* exposes fallible
operations.


We should consider just fixing this.

The history here is that FallibleTArray and InfallibleTArray used to 
bake the allocator into the class type.  There was no way to do fallible 
operations with an InfallibleTArray.


Because Sequence is used for both in parameters and return values in the 
DOM, and in parameters _must_ be fallible (web content trivially 
controls the allocation size: "var arr = []; arr.length = 1e9;"), 
Sequence inherited from FallibleTArray.


But for return values, where _we_ may control the allocation size, it 
may be reasonable to use infallible array bits if we know the array is 
small.


I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1386711 on maybe 
changing this.


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

Re: webidl: partial interfaces and build-time configuration

[Boris Zbarsky]

On 8/6/17 3:56 PM, Enrico Weigelt, metux IT consult wrote:

is there a way to use the partial interfaces for build-time
configurable features ?


Not without #ifdef.


Can I move that stuff to a separate webidl file, which is only
added in dom/webidl/moz.build when wakelocks enabled ?
(so no #ifdef's in Navigator.webidl needed)


If you try to do this, you will get a message from binding codegen that 
explicitly says this is not supported:


  TypeError: The binding build system doesn't really support partial
  interfaces which don't appear in the file in which the interface they
  are extending is defined.  Don't do this.

Of course using partial interfaces can make the #ifdef bits simpler in 
some cases.


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

Re: webidl: partial interfaces and build-time configuration

[Boris Zbarsky]

On 8/7/17 11:28 AM, Enrico Weigelt, metux IT consult wrote:

hmm, then what are the partial interfaces actually for ?


They're for use in specifications that want to add things to an existing 
interface.  They're a specification device, basically.



I had the impression that distributing (potentially optional) parts of
the interface over several files was exactly the usecase behind.


There is no implementation usecase for them.  We considered not 
supporting them at all, but decided the value of being able to 
copy/paste IDL snippets directly from specifications was worth doing a 
bit of work to add some support for the syntax.


-Boris

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

Re: Changing .idl files

[Boris Zbarsky]

On 6/14/17 9:02 AM, Benjamin Smedberg wrote:

Given that old-style addons are going away for 57, if it's possible to
delay addon-breaking IDL changes by one release until 57 that's probably
the easiest way to deal with this. We're already causing the addon
community a lot of churn.


I'd like to get some clarity on what's going on here, actually.

57 tip right now still allows old-style addons, right?  But people have 
started landing interface changes that break those addons quite badly; 
see https://bugzilla.mozilla.org/show_bug.cgi?id=1326520 for an example.


This is causing addon authors a bunch of pain as they struggle to keep 
their addons working on nightly (where they are theoretically still 
supported, per above) while also trying to port them to WebExtensions. 
I can't find a link to the bug comments complaining about this right 
now, but I recall it being connected to the nsIURI changes.


So what is the state of things at the moment?  Should we just turn off 
old-style addons on nightly?  If not, then we should probably stop 
breaking them until we _do_ turn them off.


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