One more round of improvements to Web IDL exception messages

2020-03-06 Thread Boris Zbarsky

Hello all,

We just made some more changes to Web IDL exception messages:

1) When calling ErrorResult::ThrowTypeError/ThrowRangeError, you now 
pass regular string literals or nsACString, not u"" or nsAString.  Not 
only is this more convenient for the literal cases, but the JS engine 
was converting the input string into UTF-8 anyway, so this reduces the 
amount of converting going on (though only in error cases).  See bug 
1619112 for details.


2) Exceptions thrown from binding methods now have the prefixes 
described in 
https://groups.google.com/d/msg/mozilla.dev.platform/WhTA0AmJyU8/WNcgp38cBAAJ 
not only for things thrown via ErrorResult but also for things thrown 
from the bindings themselves.  See bug 1618011.


3) If you manually initialize dictionaries from a JS::Value in your 
code, you can now pass them a BindingCallContext with a description that 
will be used as the prefix for exceptions thrown from the dictionary 
initialization.  See documentation in BindingCallContext.h.


4) More readable and informative descriptions for failures involving 
unions, for [EnforceRange] failures, and for ByteString failures.  See 
https://bug1618011.bmoattachments.org/attachment.cgi?id=9129754 for a 
bunch of testcases with before/after strings.


At this point, almost bindings stuff consistently prefixes the exception 
with the name of the interface and method involved.  The one case where 
this does not happen is when a binding method/getter/setter has the 
wrong type of object as "this".  I just filed bug 1620720 on this.


There's still the open question of what the label should looks like to 
disambiguate instance and static methods; that's tracked in bug 1614471.


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


Re: Intent to prototype and ship: lazy load images

2020-02-14 Thread Boris Zbarsky

On 2/6/20 5:26 PM, Hiroyuki Birchill Ikezoe wrote:

Is this feature enabled by default in sandboxed iframes?: no, as of now
there is no proposed flag to enable this feature in sandboxed iframes.


But is it disabled by default there?  I would assume not, unless it's 
specifically gated on sandboxing state...


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


Re: Some changes to how errors are thrown from Web IDL methods

2020-02-14 Thread Boris Zbarsky

On 2/11/20 8:57 AM, Anne van Kesteren wrote:

I don't know how much work this is, but ideally the signature is
something like throwType(safeMessage, consoleMessage), whereby
consoleMessage defaults to safeMessage or some such.


We can certainly do that.  It's "some" work for DOMException: adjusting 
the API callsites to accept the extra arg, adjusting the internal 
ErrorResult storage to store it, adjusting DOMException to store it, 
exposing a [ChromeOnly] accessor on DOMException.  I can throw this 
together pretty quickly.  Then devtools would needto use the new accessor.


For JS exceptions it would require SpiderMonkey-side changes which would 
be a lot more involved, as far as I can tell, including changes to the 
generally less-flexible "throw a TypeError" API we have to work with. 
I'd want someone on the SpiderMonkey team to do this, ideally, because 
I'm not sure which parts of this setup we really want and which we can 
throw overboard..


The hard part, of course, is knowing when to do the separate 
consoleMessage thing...


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


Re: Improvements to Web IDL exception message strings

2020-02-14 Thread Boris Zbarsky

On 2/10/20 9:57 AM, Anne van Kesteren wrote:

Would using Document.prototype.getElementById be too long?


That is a good question.

I'm going to do a bit of refactoring so we only need to change one place 
to try these ideas out and would love some feedback!


In the meantime, someone who wants to try this locally should apply the 
patches in https://bugzilla.mozilla.org/show_bug.cgi?id=1614471 and 
experiment a bit.


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


Re: Some changes to how errors are thrown from Web IDL methods

2020-02-14 Thread Boris Zbarsky

On 2/7/20 10:13 AM, Nathan Froyd wrote:

If you have other things you'd like this static analysis to be used for,
please file dependencies on bug 1613440.


Nice!  I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1614548

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


Improvements to Web IDL exception message strings

2020-02-10 Thread Boris Zbarsky

Hello all,

We just made some changes to how exception strings from ErrorResult get 
formatted [1].  The changes apply to both the Throw* DOMException 
methods and ThrowTypeError/ThrowRangeError.


In the new setup, exception messages have "%s: " prepended to them, 
where %s is replaced with one of:


* "InterfaceName.methodName", when the exception is from a method cal.
* "InterfaceName.attrName getter", when the exception is from a getter
* "InterfaceName.attrName setter", when the exception is from a setter
* "InterfaceName constructor", when the exception is from a constructor.

The idea is to give web developers a bit more context about what callee 
failed.


I have tried to go through existing message strings and remove 
duplication of that information where it existed.


The changes only affect exceptions thrown via the ErrorResult that 
bindings pass to implementation methods.  In particular, Promise 
rejections via Promise methods (as opposed to throwing on the passed-in 
ErrorResult) do not benefit from these changes; more work will need to 
happen there.


The changes also do not affect exceptions thrown via 
ErrorResult::Throw(nsresult).  As a reminder, this is deprecated and 
people should switch to the methods that provide useful error messages.


Please let me know if there are concerns around this change, suggestions 
for further improvements, etc!


-Boris

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


Re: Improvements to Web IDL exception message strings

2020-02-10 Thread Boris Zbarsky

On 2/8/20 2:31 PM, Domenic Denicola wrote:

Would you consider using something that avoids the confusion with static 
methods/properties? E.g.

- InterfaceName's methodName()
- InterfaceName's attrName getter
- InterfaceName's attrName setter


We could think about doing that, yes.  If we do, we should change all 
the existing messages that talk about InterfaceName.methodName (e.g. the 
ones that get thrown for invalid arguments, etc).


The main goal here is to give web developers an idea of which method 
they were calling quickly, without taking up space from the actual error 
message which tells them what it was they did wrong in calling it.  So 
there's a tension between brevity and getting the details right...  Your 
suggestions are pretty decent on the brevity front, though, so that 
seems workable.


I wonder what web developers think of the options here...


I'm also curious what the output would be for actually-static methods, e.g. 
CSS.escape(), DOMPointReadOnly.fromPoint(), etc.


It'd be "CSS.escape: ", etc.

You can test this now in the console using:

  CSS.escape() /* no args */
  document.getElementById() /* no args */

My changes did not affect the error messages from those, note; just used 
that same string in more places.


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


Some changes to how errors are thrown from Web IDL methods

2020-02-06 Thread Boris Zbarsky

Hello all,

I just checked in some improvements to how we report exceptions on 
ErrorResult and in promise rejections [1].  Summary:


1) The public ThrowDOMException method that takes an nsresult and a 
string is gone.  Instead, there are methods like ThrowIndexSizeError, 
ThrowHierarchyRequestError, etc, matching the error names defined at 
.  So 
whenever the spec says to "throw an SecurityError exception" or whatnot, 
you call ThrowSecurityError.  These methods can take either a string 
literal ("foo") or any nsACString.  nsPrintfCString can be used to 
produce error messages that depend on the input to the DOM method.


2) The public Promise::MaybeRejectWithDOMException method is gone. 
Instead there are MaybeRejectWithIndexSizeError, etc, methods.  Again, 
these just take the string to use for the message as input.


3) While ErrorResult::Throw taking just an nsresult still exists, it is 
deprecated and new code should not be adding new calls to it if that can 
be avoided.  Callsites that pass a constant nsresult value can be 
changed to use the above methods with meaningful error messages; I will 
be doing some of that, but would appreciate help from subject matter 
experts who can probably write better error messages than I can.  Same 
thing for ErrorResult::operator=(nsresult).


4) Promise::MaybeReject(nsresult) still exists, but is deprecated. 
Please try to convert to one of the above methods or taking an 
ErrorResult that had a meaningful exception thrown on it.


I would really like to get to the point where when web developers see 
errors in their console they don't have to guess what caused those 
errors, and having meaningful messages is the simplest way to get there.


-Boris

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


Re: PSA: You can use UTF8String from WebIDL

2020-01-21 Thread Boris Zbarsky

On 1/20/20 8:44 PM, Marcos Caceres wrote:

Is there a proposal to add this to the WebIDL spec


In the IDL spec, the USVString type is representation-agnostic: it's 
Unicode on the IDL side, and doesn't say whether you represent Unicode 
as UTF-16, UTF-8, UTF-7, UCS-32, or whatever.  So it doesn't really make 
sense to add this to the IDL spec...



My worry is having to keep IDL from specs and internal in sync (not a big deal, 
but always nice to have a single source of truth).


Indeed.  There has been some discussion in #content about automatically 
deciding whether to use UTF-8 or UTF-16 for USVString based on ... 
something, but it's not trivial to do, unfortunately.


-Boris

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


Re: Proposed W3C Charter: Audio Working Group

2020-01-21 Thread Boris Zbarsky

On 1/16/20 11:21 PM, Karl Tomlinson wrote:

Would it be appropriate to state that we don't intend to implement
the Audio Device Client API in Gecko because we don't see a need
for this additional/parallel audio API?


Does anyone other than Google want the Audio Device Client API?


* Something that might arguably be harder to implement in Web
   Audio than to implement in a new smaller API is the configurable
   `callbackBufferSize`.


The explainer for the new thing claims that the WG considered adding 
this and rejected it, right?  Should we push harder for them to consider 
it more seriously?


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


Re: PSA: Dispatching background tasks just got easier!

2020-01-01 Thread Boris Zbarsky

On 12/13/19 2:25 PM, Kristen Wright wrote:

Now that Bug 1584568  just landed I wanted to
mention the new background thread pool for general purpose and blocking IO
runnables.


Kristen,

The new setup sounds awesome.  Thanks to you and Nathan for working on this!

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


Re: How best to do async functions and XPCOM?

2019-12-16 Thread Boris Zbarsky

On 12/10/19 3:31 PM, Kris Maglione wrote:

In what way is dom::Promise annoying to use from C++?


The one thing I know about that's pretty annoying is if you receive the 
promise from someone else and want to add reactions to it. 
PromiseNativeHandler kinda works, but then you get JS::Values and have 
to extract the things you care about from them manually, which is a bit 
of a pain.


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


Re: Intent to prototype: Character encoding detector

2019-12-12 Thread Boris Zbarsky

On 12/9/19 6:24 AM, Henri Sivonen wrote:

Good point. I'll use tentative WPTs for end-to-end automated tests.


Thank you!

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


Re: How best to do async functions and XPCOM?

2019-12-06 Thread Boris Zbarsky

On 12/5/19 5:20 PM, Geoff Lankow wrote:
I'm redesigning a bunch of Thunderbird things to be asynchronous. I'd 
like to use Promises but a lot of the time I'll be far from a JS context 


Is that because both the implementation of the API and the consumer of 
the API will be C++?


For what it's worth, you are never far from a JSContext; AutoJSAPI will 
give you one.  The hard part may be finding an appropriate global to use...


In general, if the consumer or implementor of the API is JS, I would use 
JS promises.  If this is all in C++ land, MozPromise works fine, afaict.


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


Re: Intent to prototype: Character encoding detector

2019-12-05 Thread Boris Zbarsky

On 12/2/19 7:42 AM, Henri Sivonen wrote:

Since there isn't a spec and Safari doesn't implement the feature,
there are no cross-vendor tests.


Could .tentative tests be created here, on the off chance that we do 
create a spec for this at some point?


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


Re: Changes to tab min-width

2019-12-05 Thread Boris Zbarsky

On 12/5/19 6:51 AM, smurf4234332342342342342...@gmail.com wrote:

This re-introduced setting doesn't seem to exist


It's there in about:config... are you not seeing it there?

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


Re: Intent to ship: Add image/webp to default Accept header

2019-11-01 Thread Boris Zbarsky

On 10/31/19 7:31 PM, Junior Hsu wrote:

However, it doesn't not align the spec


Is that covered by https://github.com/whatwg/fetch/issues/274 or is 
there a new spec issue needed?


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


Re: Intent to ship: Promise.allSettled

2019-10-30 Thread Boris Zbarsky

On 10/30/19 6:19 PM, Jan-Ivar Bruaroey wrote:

This always seemed trivial to me to do with:

     Promise.all(promises.map(p => p.catch(e => e)))


This has different semantics from Promise.allSettled, right?  In 
particular, it effectively treats rejected promises as resolved with the 
rejection value, forgetting the fact that they were rejected. 
Promise.allSettled, on the other hand, preserves information about the 
state.


I think you can still polyfill it, using something like:

Promise.all(promises.map(p => p.then(
  v => { { status: "fulfilled", value: v } },
  e => { { status: "rejected", reason: e } }));

though I think this might create more temporary Promises than allSettled 
does...


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


Re: String contenation and temporaries

2019-10-16 Thread Boris Zbarsky

On 10/16/19 10:11 AM, Simon Giesecke wrote:

I am wondering if the following is supposed to be safe:


I would think so, yes.  That said, using string types as return values 
is not that common (using an outparam is the normal way they are used), 
and so may be under-tested.



On the treeherder builds, this seems to work fine. But reportedly,
this crashes on a release build on Mac OS X 10.13 on startup. Static
analysis does not catch a problem here. Assigning the result of
MakeColumnPairSelectionList to an intermediate variable fixes the
issue there (https://phabricator.services.mozilla.com/D49422).


It's worth trying to pin down what's going on there on Mac (e.g. by 
looking at the generated assembly) to see whether it's our bug, a 
compiler bug, or something else...


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


Elements no longer have a QueryInterface method in JS

2019-10-14 Thread Boris Zbarsky

Hello all,

Now that we no longer have xbl implements="" to worry about, I have 
landed patches to remove the QueryInterface method from Element 
instances [1] and the infrastructure for exposing QueryInterface on Web 
IDL objects in general [2].  There may still be cases in which custom 
element implementations implement QueryInterface on elements, but that's 
handled entirely on the JS side, without involving C++ code in any way.


I checked that there are no calls to the C++ QueryInterface anywhere in 
our tests and did some basic code-searching to make sure I didn't find 
any, but there might in theory be issues with codepaths which are not 
tested in automation...


-Boris

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


Re: Web IDL interfaces now require explicit [Exposed] annotations

2019-10-01 Thread Boris Zbarsky

On 10/1/19 11:39 AM, Eric Shepherd (Sheppy) wrote:

Is the page “WebIDL bindings” up to date as well?


That page describes gecko-specific aspects of IDL, so usually does not 
need to be updated for spec changes.


That said, it looks like it was never updated for 
https://bugzilla.mozilla.org/show_bug.cgi?id=1489301 (removal of 
[Exposed=System]).  I'll fix that now.


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


Re: Web IDL interfaces now require explicit [Exposed] annotations

2019-10-01 Thread Boris Zbarsky

On 10/1/19 5:58 AM, Christopher Mills wrote:

I've removed the mention of PrimaryGlobal from
https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file.
It was only a small mention.

I also removed the separate mention of the default value:


Thank you!

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


Re: Intent to unship SVGZoomAndPan interface

2019-09-29 Thread Boris Zbarsky

On 9/28/19 11:41 PM, Cameron McCormack wrote:

Both Chrome and Safari still implement the zoomAndPan IDL attribute.  The actual 
functionality behind the zoomAndPan="" attribute was never implemented in any 
browser.


Ah, ok.  In that case, removing seems pretty reasonable.


It would be good to have a historical test to ensure the property is gone, too, 
not just the SVGZoomAndPan interface.


Yes, please.

-Boris

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


Re: Intent to unship SVGZoomAndPan interface

2019-09-28 Thread Boris Zbarsky

On 9/28/19 9:41 AM, longs...@gmail.com wrote:

In [1] I intend to unship the SVGZoomAndPan interface.


To be clear, this is unshipping that interface _and_ the mixin onto 
elements that adds a `zoomAndPan` attribute on them, right?



The SVG WG decided to remove this interface in [2] as it's either not 
implemented at all or does nothing in current implementations.


Do you know whether Chrome and Safari have any specific plans to remove it?


All other browsers already pass the historical test [3] that the SVGZoomAndPan 
mixin interface must not be exposed


Sure, we could pass that by making it a mixin, not an interface, but 
that says nothing about the `zoomAndPan` attribute on SVGSVGElement and 
SVGViewElement.  What does the compat situation look like for those?


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


Web IDL interfaces now require explicit [Exposed] annotations

2019-09-27 Thread Boris Zbarsky
Starting today (on autoland,coming to m-c soon), there is no more 
[PrimaryGlobal] extended attribute on interfaces in our Web IDL, and 
therefore all interfaces need an explicit [Exposed] annotation saying 
where they are exposed (e.g. [Exposed=Window] for the case that used to 
not have any annotation and default-exposed on mainthread).


This aligns with upstream spec changes.

If someone forgets to add [Exposed] on your interface, the parser will 
helpfully complain that there are globals the interface could be exposed 
on, but it's not exposed on any of them.


Just copy/pasting IDL from specs should generally work; I believe most, 
if not all, specs updated to this upstream change a while ago.


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


Web IDL now uses mixin syntax, not "implements"

2019-09-24 Thread Boris Zbarsky
The way mixins are done in IDL has changed syntax somewhat.  Instead of 
having a [NoInterfaceObject] interface and an "implements" statement, 
the new setup looks like this:


  interface A {};

  interface mixin B {
void somethingMixedIn();
  }

  A includes B;

In-tree IDL has been updated to the new syntax.  Support for the old 
syntax has not been removed yet, but will be as soon as that patch is 
reviewed; please do not add new IDL using "implements".


The new setup is a little less featureful: mixins have no inheritance 
and cannot include other mixins.  They _do_ support partials, so you can do:


  interface A {};
  interface mixin B {};
  partial interface mixin B {
void somethingMixedIn();
  };
  A includes B;

A mixin and its partials have to in the same .webidl file, just like our 
existing rules for interfaces.  This is not enforced yet, but will be 
soon.  Similarly, the "A includes B" statement must be in the same 
.webidl file as the definition of interface A.  This part _is_ enforced.


Mixins have somewhat restricted syntax compared to interfaces (e.g. do 
not allow mixing in constructors, getter/setter operations, iterable 
declarations, etc).  This should not be a problem in practice, and 
certainly wasn't for anything we had in-tree.


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


Please aim to add informative messages to your exceptions

2019-09-13 Thread Boris Zbarsky

Hello,

ErrorResult has two kinds of exception-throwing APIs on it: the older 
ones that don't allow specifying a custom message string, and newer ones 
that do.  People should use the newer ones where possible.


That means not using the following when throwing nsresults/DOMExceptions:

  ErrorResult::Throw(nsresult)
  ErrorResult::operator=(nsresult)

and instead using:

  ErrorResult::ThrowDOMException(nsresult, const nsACString&)

which allows passing a message string that explains why the exception is 
being thrown.  Web developers will thank you and not post tweets like 
https://twitter.com/sebmck/status/1155709250225573889


When throwing TypeError or RangeError, ThrowTypeError/ThrowRangeError 
already require a message string, though I am making some changes in 
https://phabricator.services.mozilla.com/D45932 to make it a bit simpler 
to pass in custom message strings there.


Thank you all for making web developers' lives better,
Boris

P.S. We currently have a _lot_ of uses of the 
no-informative-error-message APIs.  Some of these might be things we 
don't really expect web pages to hit (e.g. exceptions when in the wrong 
type of global).  But generally speaking all ~560 uses of 
operator=(nsresult) are code smells, as are the ~1000 uses of 
Throw(NS_ERROR_DOM_*).

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


Re: New Web IDL constructor syntax

2019-09-13 Thread Boris Zbarsky

On 9/13/19 3:54 AM, Christopher Mills wrote:

I've updated the MDN WebIDL guide to include a section on the new syntax:


Chris,

Thank you!

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


ChromeConstructor has been removed

2019-09-12 Thread Boris Zbarsky
With the new constructor syntax described in 
, 
we no longer have a [ChromeConstructor] extended attribute.  If you want 
to make an interface only constructible from system code, you can do:


  interface ChromeOnlyConstructor {
[ChromeOnly]
constructor();
  };

just like for other system-only methods on the interface.

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


New Web IDL constructor syntax

2019-09-12 Thread Boris Zbarsky
As of today, the syntax for Web IDL constructors no longer involves an 
extended attribute on the interface.  There's now something that looks 
more like a method named "constructor" with no explicitly-defined return 
type.


So this:

  [Constructor(DOMString str)]
  interface MyInterface {};

is now written like so:

  interface MyInterface {
constructor(DOMString str);
  };

This means we can now specify extended attributes on the constructor, 
and therefore we no longer assume that all constructors throw.  If yours 
does, you can use [Throws] in the usual way to indicate that:


  interface ThrowingConstructor {
[Throws] constructor();
  };

It may take some time for specifications to update to the new syntax 
because not all of the tooling is updated yet; see 
https://github.com/heycam/webidl/issues/778 which tracks that.  So in 
the meantime, including new spec IDL that uses constructors may require 
some hand-editing to get it into the new form.


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


Re: The sec-approval process makes users safer

2019-09-10 Thread Boris Zbarsky

On 9/10/19 3:53 PM, Daniel Veditz wrote:

Other groups must be using that flag also


Sure, it just means "this needs a test checked in".


"Only" 718 fixed bugs with a sec- keyword have that flag.


A mere trifle!  ;)

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


Re: The sec-approval process makes users safer

2019-09-10 Thread Boris Zbarsky

On 9/10/19 12:30 PM, Boris Zbarsky wrote:
I just checked, and there are currently 826 bugs that have 
"in-testsuite?" set on them where I am the flag requester.


And overall there seem to be ~7300 bugs that have that flag set.

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


Re: The sec-approval process makes users safer

2019-09-10 Thread Boris Zbarsky

On 9/10/19 12:16 PM, Dan Mosedale wrote:

Seems like it ought to be straightforward to do something to cause
in-testsuite? flags to send mail occasionally, or show up on some
dashboard, or...


Could be worth it.

I just checked, and there are currently 826 bugs that have 
"in-testsuite?" set on them where I am the flag requester.  Clearly that 
list has not been seeing much love...


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


Re: Intent to Prototype: Have window.outerHeight/outerWidth lie and report the innerHeight/innerWidth

2019-09-08 Thread Boris Zbarsky

On 9/8/19 8:28 AM, Andreas Tolfsen wrote:

It would be fine of course to move the existing behaviour to
chrome-only mozOuterWidth/mozOuterHeight


For what it's worth, out current outerWidth/outerHeight getters already 
check who the caller is and don't apply the Tor bits if the caller is 
system code.  So allowing that to continue working would not be very hard.


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


Re: Intent to Ship - Support XCTO: nosniff for navigations

2019-09-05 Thread Boris Zbarsky

On 9/5/19 9:20 AM, Sebastian Streich wrote:

In Firefox 70 I intend to enable nosniff support for
page navigations by default.


We're still doing stream converters for navigations even if that header 
is sent.  Is that intended?  I filed 
https://bugzilla.mozilla.org/show_bug.cgi?id=1579176 to track that.



If a server's response does not include any mime-type but sets the response
header "XCTO: nosniff" then Firefox will prompt the user to download the
file


Is that definitely known to be true?  Based on code inspection it looks 
like this case will set the type to UNKNOWN_CONTENT_TYPE, then keep 
trying to do stream conversion things with it 20 times in a row (or 
whatever the "general.document_open_conversion_depth_limit" pref is set 
to), and then kick it over to the helper app handler.  After that what 
happens depends on whether the user might have a helper app defined for 
that type and so forth.  If we actually mean to force a download, we 
should probably be doing so explicitly.


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


Re: Intent to ship: multi-keyword values on the CSS 'display' property

2019-08-26 Thread Boris Zbarsky

On 8/19/19 3:42 PM, Mats Palmgren wrote:

Your point is well taken but it's an independent issue.


Sure.  I'm just saying that I suspect some of the combinations may be 
hard to implement using anon boxes, depending on what combinations are 
allowed.


For example, can one have a thing which is "table-cell" on the outside 
and "flex" on the inside, per spec?



I don't know what their plans are.  I haven't seen any public
announcements one way or another.


It's worth trying to find out, and in particular to find out whether 
what we plan to ship is compatible with what they plan to ship.


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


Re: Intent to ship: multi-keyword values on the CSS 'display' property

2019-08-14 Thread Boris Zbarsky

On 8/14/19 12:37 PM, Mats Palmgren wrote:

This first patch set adds support for the new syntax
only, but no new box types (I'll add those separately in a bit).


In general, it seems like we should think about how to integrate this 
stuff into layout in a better way than anonymous boxes everywhere.  In 
particular, we may want to consider changing nsIFrame such that we have 
it point to a "how I look to my parent" class and a "how I manage my 
kids or paint myself" class and be able to mix and match those.  That's 
out of scope for this intent, but if we plan to start adding various 
implementations of multiple keywords for display this seems like it 
would be the way to go about it...



Other browsers: Other UAs don't support this yet, AFAIK.


Do they plan to?

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


Re: Native actor refcounting support in IPDL

2019-08-01 Thread Boris Zbarsky

On 8/1/19 3:11 PM, Nika Layzell wrote:

Bug 1550560 (https://bugzilla.mozilla.org/show_bug.cgi?id=1550560) landed
recently, adding native support for declaring actors as *refcounted*.


Would that allow us to add MOZ_CAN_RUN_SCRIPT bits to the generated code 
for those cases?


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


Re: Intent to ship: Blocking Worker/SharedWorker with non-JS MIME type

2019-07-25 Thread Boris Zbarsky

On 7/25/19 6:22 AM, Tom Schuster wrote:

After asking the Chrome team for clarification
(https://github.com/whatwg/html/issues/3255), they are interested in
shipping this, but need more time and information.
So I propose restricting this change to Beta/Nightly and to wait for
them or until we see too much fallout.


Makes sense.


importScripts was successful, even though it had higher usage. If we
are going to delay shipping this,
we might as well look into adding those counters.


Might make it easier to convince Chrome if we had this data.

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


Re: Intent to ship: Blocking Worker/SharedWorker with non-JS MIME type

2019-07-22 Thread Boris Zbarsky

On 7/22/19 6:22 AM, Tom Schuster wrote:

This was also discussed at https://github.com/whatwg/html/issues/3255.
It seems like Chrome does NOT plan on shipping this at the moment.


Does "at the moment" mean they are open to shipping it in the future if 
we ship it and don't run into web compat issues, or that they are not 
planning to ship at all?  What are Safari's plans here?  What is the 
proposed path to interop?



We didn't dig too deeply into this data, but one idea was
that a lot of worker scripts are actually 404 text/html error pages.


This is something telemetry could easily measure, yes?  Only record 
worker script types for responses that would actually get processed 
(i.e. not HTTP 4xx responses).  Is there a reason not to do that before 
shipping this change?


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


Re: Firefox command seems to be a wrapper

2019-07-20 Thread Boris Zbarsky

On 7/20/19 9:04 AM, Mahmood Naderan wrote:

However, I am not sure if the tracer logs *the process that fetches data
from web* or not.


Using the definite article ("the") there, is fundamentally wrong.

When you load a web page in Firefox, there are at least 2 processes 
involved in "fetching data from web", possibly more, depending on the 
exact configuration.  At the very least there is the process where the 
actual socket access happens (which is probably the "parent" Firefox 
process, which is the first one that starts, in your case), but which 
data should be fetched and what's done with it is largely determined in 
a different ("child") process.


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


Re: Group email address

2019-07-16 Thread Boris Zbarsky

On 7/16/19 10:01 AM, Mahmood Naderan wrote:

When I post an email to mozilla.dev.platf...@googlegroups.com from my gmail 
account


The right e-mail address for this list is dev-platform@lists.mozilla.org.

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


Re: Firefox command seems to be a wrapper

2019-07-15 Thread Boris Zbarsky

On 7/15/19 11:51 AM, Mahmood Naderan wrote:

Overall, firefox command is a wrapper and I am seeking for a way to access the 
main firefox.


Is just "the main firefox" enough for the tracing you want to do?  Note 
that all the website rendering happens in separate processes, not the 
Firefox UI process.  So chances are you want to be able to follow 
subprocess executions in your tracing tool anyway...


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


Re: Resolving URLs in c++

2019-07-12 Thread Boris Zbarsky

On 7/12/19 1:57 AM, mcace...@mozilla.com wrote:

Do we have an equivalent in Gecko?


No, but it would no be a bad idea to add something...


Right now, in Gecko, I'm having to do this:


Yeah, that's kinda ugly...


 rv = NS_NewURI(getter_AddRefs(resolvedUri), aData.mUrl.Value(), nullptr,
doc->GetDocumentURI(), nsContentUtils::GetIOService());


You could simplify this a bit by calling 
nsContentUtils::ewURIWithDocumentCharset, but that doesn't solve most of 
the issue.


Also, this clearly shows that our current setup is too easy to mess up: 
per spec this should be using the document's base URI, not the 
document's URI, as the base URI.



Also, having to use `nsIURI` feels kinda sad when we implement the URL 
Standard Can we use URL  somehow be used as a drop in replacement for 
nsIURI?


Just to be clear, our URL Standard impl will swallow some of those 
errors this code is checking for and just return empty strings if they 
happen.  And of course it uses nsIURI under the hood.


Past that, it doesn't really have a nicer API (from C++) than nsIURI 
does, right?


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


Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

2019-07-04 Thread Boris Zbarsky

On 7/4/19 10:11 PM, Gerald Squelart wrote:

- I found plenty of `unsigned`s around, more than `uint32_t`s.


How many are in code that predates the ability to use uint32_t, though?


- Our latest coding style [1] points at Google's, which has a section about Integer Types 
[3], and the basic gist is: Use plain `int` for "not-too-big" numbers


If you can 100% guarantee that they will not be too big, right?

(In particular, for generation counters I would be somewhat worried 
about making such a guarantee.)



never use any unsigned type unless you work with bitfields or need 2^N overflow 
(in particular, don't use unsigned for always-positive numbers, use signed and 
assertions instead).


Do you happen to know why?  Is this due to worries about underflow or 
odd behavior on subtraction or something?


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


Re: Intent to implement and ship: Exposure of Geometry Interfaces to Workers

2019-06-17 Thread Boris Zbarsky

On 6/17/19 11:02 AM, saschan...@gmail.com wrote:

Summary: Expose DOMMatrix/DOMPoint/DOMQuad/DOMRect to workers and enable 
structured cloning for them.


Note that this also allows storing these objects in IndexedDB, via 
implementing the equivalent of 
https://html.spec.whatwg.org/multipage/structured-data.html#serializable-objects 
for them.


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


Intent to unship: DOMError

2019-06-17 Thread Boris Zbarsky

We plan to unship DOMError in Firefox 69.

This type has been removed from all specs and our code; the only way to 
get one is to construct one explicitly from JS.  The constructor 
telemetry at 
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2019-06-07_spill=0=__none__!__none__!__none___channel_version=beta%252F67=USE_COUNTER2_DOMERRORCONSTRUCTOR_PAGE_channel_version=null=*=Firefox=1_by_value=0_keys=submissions_date=2019-03-27=0=1_submission_date=0 
shows it's used on something like 0.0002% of pageloads.


Safari has already dropped support for DOMError, per 
https://wpt.fyi/results/dom/historical.html?label=master=experimental


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


Re: Intent to unship:

2019-06-14 Thread Boris Zbarsky

On 6/14/19 7:02 AM, Henri Sivonen wrote:

Thanks for the removal. Do we have enterprise Web developer-facing
documentation on 1) how TLS client cert enrollment should work now or
2) if there is no in-browser client cert enrollment path anymore, what
concretely should be used instead? 


For what it's worth, the one case I am familiar with (MIT) has a native 
app you run to manage your keystore for non-Firefox browsers (presumably 
by changing the OS keystore) and uses  in Firefox.  See 
http://kb.mit.edu/confluence/display/istcontrib/Certificates+Landing+Page#CertificatesLandingPage-GetCertificates


How viable is it to extend such a native app to munge the Firefox 
keystore?  If it is, we should probably document it...


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


Re: Intent to implement and ship: overflow-block and overflow-inline CSS properties

2019-06-14 Thread Boris Zbarsky

On 6/14/19 6:23 AM, violet wrote:

Preference behind which this will be implemented: 
layout.css.overflow-logical.enabled


Thank you.

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


Re: Intent to implement and ship: overflow-block and overflow-inline CSS properties

2019-06-13 Thread Boris Zbarsky

On 6/13/19 4:15 AM, violet wrote:

Preference behind which this will be implemented: none.


It's probably a good idea to have a pref controlling whether these get 
parsed, so we can disable if needed if there's an issue, given that no 
one has shipped these yet in a final release.  Or are there technical 
reasons that make this difficult?


Are these just logical versions of the existing overflow-x and 
overflow-y properties?


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


Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

2019-06-11 Thread Boris Zbarsky

On 6/11/19 7:49 AM, Kartikaya Gupta wrote:

IIRC another difference between prefs in all.js and gfxPrefs was that if a
pref was not listed in all.js, you couldn't use it in the
{test-,ref-,}pref(...) annotations in reftest.list files.


That restriction is due to the code at 
https://searchfox.org/mozilla-central/rev/0da35261b6789eec65476dbdd4913df6e235af6d/layout/tools/reftest/reftest.jsm#675-699 
refusing to set the new value if it can't get the old 
(to-be-restored-later) value.  From that point of view, StaticPrefs and 
all.js are equivalent: both provide an existing value to work with.


That said, we could probably improve this code to restore 
no-value-set-before prefs via clearUserPref so it would not have this 
restriction at all.


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


Re: NS_NewURI is now thread-safe

2019-06-10 Thread Boris Zbarsky

On 6/10/19 4:07 PM, Valentin Gosu wrote:

which means nsIURI
can now be safely used and created on any thread via NS_NewURI.


That's awesome news!


and if you want to add any other special scheme to Gecko you should do so in 
NS_NewURI in
nsNetUtil.cpp


Here "special" is in the sense of "Parsed as anything other than a basic 
nsSimpleURI"?


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


Re: Intent to implement and ship: blob.text(), blob.arrayBuffer(), blob.stream()

2019-06-07 Thread Boris Zbarsky

On 6/7/19 8:47 AM, Andrea Marchesini wrote:

Summary: implement and ship 3 new methods to read Blob contents:
blob.text(), blob.arrayBuffer() and blob.stream().


Looks good to me.

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


Re: Removing --enable-shared-js [Was: Rust and --enable-shared-js]

2019-05-21 Thread Boris Zbarsky

On 5/21/19 9:55 PM, Mike Hommey wrote:

Considering this has apparently been broken for so long, I guess nobody
will object to me removing the option for Gecko builds?


It's probably fine, yeah...

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


Re: Outline of a plan to remove all XUL documents from mozilla-central

2019-05-14 Thread Boris Zbarsky

On 5/14/19 11:32 AM, Brian Grinstead wrote:

3. For files where there are no (important) XUL elements in the
markup, rename .xul->.html.


Brian,

Could you expand on why this is preferable (when possible) to renaming 
them to .xhtml?  Are there benefits to .html over .xhtml for our 
purposes here?  Is this mostly around how we deal with our tests, as 
opposed to actual parts of the UI?


In general, the plan sounds great!

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


Re: Changes to how we track regressions in Bugzilla

2019-04-30 Thread Boris Zbarsky

On 4/29/19 6:15 PM, Emma Humphries wrote:

We’re replacing the regression and regressionwindow-wanted keywords, and
the has-regression-range field with is_regression


Emma,

Thank you, the new setup seems a lot clearer about the state of the bug 
in terms of regression tracking!


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


Re: Apple Notary Service and Debugging Impact

2019-04-11 Thread Boris Zbarsky

On 4/11/19 3:07 AM, Haik Aftandilian wrote:

With notarization, Nightly channel builds will not be debuggable unless the
system is booted with system integrity protection (SIP)[1] disabled.


Do you know whether sampling via Activity Monitor's "Sample Process" 
option or via Instruments will still work?


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


Re: Proposal to remove unnecessary [type] attributes on script tags in mozilla-central

2019-04-09 Thread Boris Zbarsky

On 4/9/19 10:37 AM, Brian Grinstead wrote:

I'll think some more about if there’s a way to limit the risk of losing test 
coverage.


One simple thing is to restrict the change to 

Re: Intent to deprecate - linux32 tests starting with Firefox 69

2019-04-05 Thread Boris Zbarsky

On 4/5/19 10:20 AM, Kartikaya Gupta wrote:

If we can drop that then we can remove a bunch of complexity
and code paths.


Are we talking about just dropping linux32 _tests_, or dropping linux32 
_support_?


Because if we're keeping support, and linux32 is the only non-APZ 
confiration, then not only do we need to keep the non-APZ code but we 
need to keep the tests that might depend on APZ vs non-APZ, no?


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


Re: Intent to deprecate - linux32 tests starting with Firefox 69

2019-04-05 Thread Boris Zbarsky

On 4/5/19 9:35 AM, jma...@mozilla.com wrote:

As our next ESR is upcoming, I would like to turn off linux32 on Firefox 69 and 
let it ride the trains and stay on 68 ESR.  This will allow builds/tests to be 
supported with security updates into 2021.


The only thing I've used the linux32 tests for recently was on try to 
get tests that:


1) Compile and run in finite time (unlike Windows and Mac)
2) Have useful crash stacks (unlike linux64; see 
).


When drop linux32, we should make sure we treat stacks in logs on 
linux64 as a priority...


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


Re: Creating a new mach command for adding tests

2019-04-01 Thread Boris Zbarsky

On 4/1/19 2:36 PM, Brian Grinstead wrote:

 When you run the command it will create a file with the appropriate 
boilerplate and add it to the manifest file (chrome.ini, mochitest.ini, 
browser.ini depending on the type).


Brian, thank you for putting this together!

I have one concern with the mach bits themselves: It looks like the way 
the type-detection works is that it looks for "browser_" in the test 
name, and if that's present uses browser.ini.  Otherwise it uses 
chrome.ini if it's present in the dir, else mochitest.ini if it's 
present, else errors out.


We have a fair number of dirs that have both a chrome.ini _and_ a 
mochitest.ini, and defaulting to chrome.ini for those dirs seems odd. 
It might be better to error out of the filename is test_foo and the dir 
has both chrome.ini and mochitest.ini and tell the developer to pick one 
or the other explicitly.



Links to bugs/comments/etc can be added in the test if they are relevant, but I 
don't know that it's important enough to add another step in front of getting a 
useful test case built. I did also consider adding a TODO comment in the 
template to add a bug link (though in a single place instead of 4), but not to 
require that information up front.


I think realistically getting to the bug through the version control 
history is reasonable, so there's not that much reason to have a bug 
link in the test itself.


I would further argue that the  in just about all our mochitests 
is pointless and could go from the template.


I do have one other question on the templates: for mochitest-plain, 
add_task is a pretty rare thing to do, so I'm not sure defaulting the 
template to that makes sense.  For mochitest-chrome I'm not really sure; 
for mochitest-browse I agree that defaulting to add_task makes sense.


For the cases where we don't default to add_task (if any) we probably 
shouldn't include AddTask.js either, like we don't include other things 
that are helpful in only some test files (EventUtils.js, etc).


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


Re: How to reliably make an ArrayBufferView wrapped?

2019-03-25 Thread Boris Zbarsky

On 3/25/19 11:22 AM, violet.bugrep...@gmail.com wrote:

I think it should be a browser test, because I need to call IndexedDB.


OK, makes sense.

In that case, the simplest option is to pick a browser test that 
involves Xray wrappers and modify it so you have an Xray to an 
ArrayBufferView.


If IndexedDB works in system-principal pages, you could take something 
like 
https://searchfox.org/mozilla-central/source/js/xpconnect/tests/chrome/test_xrayToJS.xul 
and use a similar setup.  So create a mochitest-chrome test that loads 
file_empty.html or equivalent in a subframe, then do:


  var view = new 
(document.getElementById('ifr').contentWindow.Int32Array)(5);


or so and go on from there.

If you run into trouble, please feel free to ping me on IRC ("bz" on 
#content or #developers) or mail me, or post here.


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


Re: How to reliably make an ArrayBufferView wrapped?

2019-03-25 Thread Boris Zbarsky

On 3/25/19 4:22 AM, violet.bugrep...@gmail.com wrote:

In the test, I want to make sure the object is indeed a wrapped one. Is there a 
reliable way to write JavaScript code to achieve this?


Are you trying to write a JS shell test or a browser test?

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


Re: Intent to implement: Limit the maximum life-time of cookies set through document.cookie to seven days

2019-03-08 Thread Boris Zbarsky

On 3/7/19 7:31 PM, Ehsan Akhgari wrote:

*web-platform-tests*: This is an intervention which different engines do
not agree on yet.  Creating a web-platform-test for it would be very simple
but it will be failing in the engines that do not agree with the
intervention.  I'm not sure what the recommendation for testing these types
of changes is, would be happy to submit a test if there is a path for
getting them accepted into wpt.


Other vendors have been landing tests with ".tentative" as the last part 
of the filename before the suffixes the test harness expects (so e.g. 
"web-locks/mode-shared.tentative.https.any.js").


I think doing that here is fine; we may want the tests or the commit 
message involved to point to an explainer or something tracking the need 
for a spec change or something like that...


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


Re: Intent to ship: Dynamic module imports (JS 'import()' syntax)

2019-03-07 Thread Boris Zbarsky

On 3/7/19 10:27 PM, Martin Thomson wrote:

Is there a way that doesn't rely on eval or eval-like mechanisms?


I suspect the only detectable thing here (and Jon might wake up tomorrow 
and tell me I'm wrong!) is that import('stuff') is a syntax error 
without the support but is not a syntax error otherwise.


That means you need to trigger at least a new parse of some JS that you 
control to run the detection.


Now you could probably manage this with something like (using non-inline 
scripts for all this stuff):


  
var oldError = window.onerror;
window.onerror = function(...args) {
  /* check for syntax error */
}
  
  function() { import(''); }
  window.onerror = oldError;

or so.

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


Re: Intent to ship: Dynamic module imports (JS 'import()' syntax)

2019-03-07 Thread Boris Zbarsky

On 3/7/19 6:14 PM, rekt...@gmail.com wrote:

Is there any way to feature detect support for import() syntax?


In Firefox, yes, as far as I can tell:

  try {
new Function("import('')");
// supported
  } catch (e) {
// not supported
  }

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


Intent to ship: aligning with the spec on document.open behavior and removing wyciwyg

2019-02-22 Thread Boris Zbarsky
Summary: historically in Gecko document.open created a new global and 
new session history entry (unless "replace" was passed).  We also stored 
the written data in a "wyciwyg" cache entry so it could participate 
meaningfully in session history.  I plan to change these behaviors and 
simplify the behavior of document.open to align with the spec and other 
browsers.  All the "wyciwyg" bits in the tree are being removed in the 
process.


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

Link to standard: 
https://html.spec.whatwg.org/multipage/dynamic-markup-insertion.html#document-open-steps


Platforms: all

Target release: 67

Devtools bug: none needed.

Other engines: already implement the model we're aligning with, generally.

web-platform-tests: 
http://w3c-test.org/html/webappapis/dynamic-markup-insertion/opening-the-input-stream/


There is a certain amount of compat risk here, since this is changing a 
very longstanding behavior.  I'm hoping that by aligning with the spec 
(except for a few edge cases like calling document.open() on a document 
whose iframe has been removed from the DOM that we used to no-op and 
continue to no-op) and other browsers we keep the risk pretty low.


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


Intent to ship: sharing compartments across globals on the web and adjusting document.domain behavior

2019-02-22 Thread Boris Zbarsky
Summary: We plan to place multiple globals in a single compartment to 
reduce the memory overhead due to cross-compartment wrappers and the 
performance overhead of traversing those wrappers.  Globals will be 
placed in the same compartment if: (1) they are same-origin (ignoring 
document.domain) and (2) they are nested under the same toplevel 
document.  That is, a document can be same-compartment with a subframe, 
but not with a new thing it opens via window.open().


There are various reasons for this last restriction, but it's mainly 
there because we ran into performance/memory regressions due to things 
not being collected as expeditiously as we'd like when we put things 
from different toplevel loads in the same compartment.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1523843 though a bunch 
of the work happened in the various depedencies of 
https://bugzilla.mozilla.org/show_bug.cgi?id=1357862


Link to standard: No standard for the compartment bit per se.  However, 
in the course of this work we aligned our document.domain behavior to be 
much more like other browsers, since we no longer have a compartment 
boundary to revoke access to random objects when document.domain 
changes.  This part is arguably aligning us more closely with standards too.


Platforms: all

Target release: 67

Devtools bug: none needed.

Other engines: already implement the document.domain model we moved to.

web-platform-tests: I added some at 
http://w3c-test.org/html/browsers/origin/relaxing-the-same-origin-restriction/document_domain_access_details.sub.html 
(though note that the last two tests fail right now because of a bug in 
the w3c-test.org harness).


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


Re: Intent to Unship: Fake Plugins

2019-02-21 Thread Boris Zbarsky

On 2/21/19 3:44 PM, Kyle Machulis wrote:

and Pdf.js is still shipping as a stream handler for the
time being.


Note that there are a bunch of issues with that (e.g. around 
window.print()), which we were hoping fake plugins would solve.  If that 
plan has been abandoned, it might be worth finding some resources to 
solve those problems in some other way, because they are causing compat 
pain...


Apart from that, removing fake plugins sounds good.

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


Re: C++ method definition comments

2019-02-04 Thread Boris Zbarsky

On 1/30/19 10:19 AM, Ehsan Akhgari wrote:

What tool do you use which has difficulty showing function names in diffs
right now?  It seems to work fine for me both in git and hgweb...


"hg diff" and "git diff" both fail at this over here when there is a /* 
comment */ before the function name.  hg version 4.4.2 and git version 
2.14.5.


For example, if you make a change in the middle of 
nsContentUtils::AttemptLargeAllocationLoad and then hg diff or git diff, 
it will claim your change is in 
nsContentUtils::LookupCustomElementDefinition.  I just ran into this 
while trying to read a patch someone asked for review on.


If there is no comment before the function name, it works.

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


Re: Does mozilla allow modification of Strings

2019-01-29 Thread Boris Zbarsky

On 1/29/19 4:37 AM, Nanday Dan wrote:

I added the variable to FakeString.  But still application crashes.


Sure, unless you also fixed the Rust interop issue.

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


Re: Does mozilla allow modification of Strings

2019-01-28 Thread Boris Zbarsky

On 1/28/19 7:51 AM, edusubscr...@gmail.com wrote:

Building was successful.


I'm really surprised the static assert at 
https://searchfox.org/mozilla-central/rev/4faab2f1b697827b93e16cb798b22b197e5235c9/dom/bindings/FakeString.h#146-147 
did not trigger, given the changes you described...


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


Re: Intent to Implement and Ship: CSS padding-block and padding-inline shorthands

2019-01-14 Thread Boris Zbarsky

On 1/14/19 9:09 PM, fantasai wrote:

I have no idea why I did that. Fixed.


Thank you!


Yes, the spec reflects general consensus, and has been explicitly cleared
for shipping by the CSSWG (as of several years). See issue at the bottom
of the intro:
   https://www.w3.org/TR/css-logical-1/#intro


Perfect, thank you for the pointer.

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


Re: Intent to Implement and Ship: CSS padding-block and padding-inline shorthands

2019-01-14 Thread Boris Zbarsky

On 1/14/19 12:58 PM, Mats Palmgren wrote:
Link to standard: 
https://drafts.csswg.org/css-logical/#propdef-padding-inline


Two quick questions on the spec:

1) 'padding-block-start' is defined as:

  Value:  <‘padding-top’>

while 'padding-block' is defined as:

  Value:  <‘padding-left’>{1,2}

It probably doesn't matter too much because padding-top and padding-left 
have the same value space, but it's a bit weird and makes one go 
sleuthing to ensure that they do.  Do you know whether this is 
purposeful or just a typo?


2) We are just implementing the padding shorthands for now, not the 
margin ones?


Do other browser engines implement this? No, 
https://wpt.fyi/results/css/css-logical/logical-box-padding.html


Do they plan to?  That is, is the spec reflecting some sort of general 
consensus?


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


Re: Intent to ship: TextEncoder.encodeInto() - UTF-8 encode into caller-provided buffer

2019-01-14 Thread Boris Zbarsky

On 1/14/19 4:28 AM, Henri Sivonen wrote:

This is now an "intent to ship". The feature landed in the spec, in
WPT and in Gecko (targeting 66 release).


Where do other browsers stand on this feature, do you know?

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


Re: XPCOM Tidying Proposal

2019-01-11 Thread Boris Zbarsky

On 1/10/19 6:15 PM, Kyle Machulis wrote:

- Removal of [noscript] methods in interfaces in favor of direct calls via
Cast() where possible.


This seems generally reasonably, though I'd like to put in a bit of a 
vote for the pattern I recently used for 
nsIPrincipal::IsSystemPrincipal, which looks like this:


IDL:

%{C++
  inline bool IsSystemPrincipal() const;
%}

C++ (in BasePrincipal.h):

  inline bool nsIPrincipal::IsSystemPrincipal() const {
return BasePrincipal::Cast(this)->IsSystemPrincipal();
  }

which avoids having the Cast() calls scattered all over the place...


- Direct getters through Cast() where possible, infallible (also where
possible) otherwise.


Yes, please.

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


Intent to implement and ship: forced case-sensitive attribute selector matching

2018-12-11 Thread Boris Zbarsky
Summary: When matching CSS attribute selectors against HTML, some 
attribute names lead to case-sensitive value matching, while others use 
ASCII-case-insensitive matching.  The proposed feature adds an 's' flag 
on attribute selectors that forces case-sensitive matching, just like 
the existing 'i' flag forces ASCII-case-insensitive matching.


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

Standard: https://drafts.csswg.org/selectors-4/#attribute-case

Platform coverage: all

Estimated or target release: Firefox 66.

Preference behind which this will be implemented: None.

Is this feature enabled by default in sandboxed iframes? Yes.

DevTools bug: None needed, as far as I can tell.

Do other browser engines implement this?  Not yet.  This is a new 
addition to the standard.


web-platform-tests: This is tested in the tests in 
http://w3c-test.org/css/selectors/attribute-selectors/attribute-case/


Is this feature restricted to secure contexts?  No, like other CSS 
syntax features.


Spec stability: Not 100% clear, but I expect it's pretty stable; on the 
spec level this is a tiny change and there's not much controversy about 
which letter to use for the flag, I would think.


Security & Privacy Concerns: None

Web designer / developer use-cases AKA Why a developer would use Feature 
X? https://github.com/w3c/csswg-drafts/issues/2101#issue-280846560 
describes the main use-case: HTML list styling needs this, because 
type="a" and type="A" are different.


Example usage: [foo="bar" s] { color: fuschia }

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


Re: The upcoming C/C++ coding style change

2018-11-29 Thread Boris Zbarsky

On 11/29/18 11:40 AM, Ehsan Akhgari wrote:

Yes, that is true sadly.  But to be fair here, old mq patches that do not
apply due to age are already beyond saving with any kind of automated
tooling, and they require manual work to get them applied first.  :-/


Sure.


That's not true.  clang-format can happily format diffs.  When formatting
diffs though it tries to format your changes, not the context around the
diffs


Ah, OK.  That makes sense.


   * Update your working tree to the parent of the commit that did the
reformat.


This also makes sense.

Have we considered adding an easy-to-remember tag for that commit to 
make that easier in the future?


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


Re: The upcoming C/C++ coding style change

2018-11-29 Thread Boris Zbarsky

On 11/29/18 11:40 AM, Ehsan Akhgari wrote:

Yes, that is true sadly.  But to be fair here, old mq patches that do not
apply due to age are already beyond saving with any kind of automated
tooling, and they require manual work to get them applied first.  :-/


Sure.


That's not true.  clang-format can happily format diffs.  When formatting
diffs though it tries to format your changes, not the context around the
diffs


Ah, OK.  That makes sense.


   * Update your working tree to the parent of the commit that did the
reformat.


This also makes sense.

Have we considered adding an easy-to-remember tag for that commit to 
make that easier in the future?


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


Re: The upcoming C/C++ coding style change

2018-11-29 Thread Boris Zbarsky

On 11/29/18 11:12 AM, Ehsan Akhgari wrote:

   * Pull from a pre-reformat of the tree, run ./mach bootstrap to install
hg-formatsource.
   * Do a one-time translation of your mq queue to a set of commits.
   * Pull from hg.mozilla.org to pick up the reformat commit.
   * Do a one-time translation of your mq queue back to a series of patches.


So just to be clear, I have a dozen or so queues with hundreds of 
patches in them, not all of which will immediately apply due to age.  So 
this is not a simple operation, unfortunately...


I guess there's no real way to clang-format diffs, so maybe the answer 
is manual merging when I actually need those patches.


-Boris


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


Re: The upcoming C/C++ coding style change

2018-11-29 Thread Boris Zbarsky

On 11/29/18 7:38 AM, Sylvestre Ledru wrote:
This extension will automatically rebase the local changes to avoid 
conflicts.


Sylvestre,

Will it also update mq patches, or just in-repo commits?

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


Re: Rationalising Linux audio backend support

2018-11-24 Thread Boris Zbarsky

On 11/24/18 6:35 AM, susa...@gmail.com wrote:

It is strange to hear "we are misserable impotent at ALSA" from Mozilla devs...

Well, anyway, 2 years after your decision - how is feeling each time alsa-only 
user courses you? Enjoy!


I'm sorry to have to say this, but the post above fails to observe the 
"be respectful" and "no personal attacks" guidelines.  Please see 
https://www.mozilla.org/en-US/about/governance/policies/participation/ 
for more details.  Please comply with those in the future if you decide 
to post here.


If you have a specific argument you want to make about resource 
allocation, please feel free to do so.  Such arguments should probably 
be accompanied by either new factual information that was not considered 
when making the existing allocation decisions or by an argument that 
priorities should now be different from what they were then.  All this 
can and should be done without being rude to people.


Thank you,
Boris.

P.S.  Same thing in Russian, just to make sure we're on the same page:

К сожалению ваш пост не следует принципам "будь почтительным" и "не 
нападай на людей" из 
. 
 В будущем, пожалуйста следуйте этим принципам.


Если вы хотите оспорить принятое решение о распререлении ресурсов, 
пожалуйста, оспаривайте.  Для этого нужно либо предоставить новые факты 
которые не были учтены при принятии решения либо аргументировать, что 
приоритеты изменились или должны измениться.  Все это можно и нужно 
сделать в вежливой форме.

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


Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements

2018-11-22 Thread Boris Zbarsky

On 11/22/18 1:06 AM, Ehsan Akhgari wrote:

Can one do noreferrer with window.open()?



Yes, by passing 'noopener' in the features argument:
https://html.spec.whatwg.org/multipage/window-object.html#apis-for-creating-and-navigating-browsing-contexts-by-name:disowned-its-opener


But we're trying to _have_ an opener; that's why we're here to start 
with.  We're talking about noreferrer.



Which reminds me, it's impossible to block opener reference creation upon
form submission right now as far as I can tell.


Yes.  Right now  doesn't have a thing like "rel" to pass along 
directives like "noopener".  Maybe we should get that fixed in the spec 
somehow.



I wonder if it makes sense to make a similar change here, to make  imply noopener behaviour and then if that proves to be Web
compatible, propose to change the spec to pass false there?


It might indeed.

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


Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements

2018-11-21 Thread Boris Zbarsky

On 11/21/18 11:50 PM, Ehsan Akhgari wrote:

Would it be OK if the answer to that question be "use window.open()"?


Can one do noreferrer with window.open()?

Also, if your thing doing the navigation is a , not , then 
window.open is pretty hard to use for that.  Then again, target="_blank"> is not that common...


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


Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements

2018-11-21 Thread Boris Zbarsky

On 11/21/18 2:22 PM, Daniel Veditz wrote:

"opener" doesn't exist


It does in WebKit's proposed changes and in our implementation of them.


You'd specify a target
name other than "_blank" to indicate it's a context you care about


This seems backwards.  What matters is whether the context should care 
about _you_, not whether you care about it.  If you want to open a 
guaranteed-new context that can then communicate with you, how should 
you do that, exactly?  Making up target names (which you have no way to 
guarantee are unique) seems like a bad approach to that.


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


Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method

2018-11-20 Thread Boris Zbarsky

On 11/20/18 9:19 AM, Anne van Kesteren wrote:

Similar, e.g., https://bugs.chromium.org/p/chromium/issues/detail?id=872772.
Doesn't seem like a high priority for anyone to fix.


Well... If:

1) All the browsers agree here (do they?)
2) There are concerns that there may be sites depending on the behavior.
3) If those concerns are true there would be security issues caused by 
changing the behavior.


then why would we expect anyone to ever change the behavior?

-Boris

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


Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method

2018-11-20 Thread Boris Zbarsky

On 11/20/18 8:55 AM, Honza Bambas wrote:
because comma can be contained in a single header value 
(against what the spec says).  We can't correctly separate the headers 
by commas, potentially even opening security holes if we do that blindly.


Do we know what other UAs do here?

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


Re: nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method

2018-11-19 Thread Boris Zbarsky

On 11/19/18 5:07 PM, john.biel...@googlemail.com wrote:

WWW-Authenticate: X-MobileMe-AuthToken realm="Newcastle", Basic 
realm="Newcastle"


I expect this would work if you sent it as:

WWW-Authenticate: X-MobileMe-AuthToken realm="Newcastle"
WWW-Authenticate: Basic realm="Newcastle"

Yes, per spec they are theoretically supposed to be the same. But 
https://searchfox.org/mozilla-central/rev/b03a62c3c82316e733a3b09622c1cb7e59f64cc3/netwerk/protocol/http/nsHttpHeaderArray.h#268,271-273 
is probably relevant here: ',' appears in some authentication 
information in the wild, so you can't just split WWW-Authenticate on 
commas to get a list of authentication methods.


Whether this is a bug is something I'll let the networking team comment 
on; I don't know the full set of compat constraints here.


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


Re: Intent to implement: Reporting API

2018-11-16 Thread Boris Zbarsky

On 11/15/18 4:17 PM, Andrea Marchesini wrote:

I think we should implement this API for these reasons:


OK.  I guess we should keep an eye on the privacy implications, but 
otherwise probably fine to go ahead.


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


Re: Intent to implement: Reporting API

2018-11-15 Thread Boris Zbarsky

On 11/15/18 9:52 AM, Ehsan Akhgari wrote:

The idea is to use Feature Policy in report-only mode


There is no report-only mode in the Feature Policy spec, nor in our 
implementation.  See the note at the end of 
https://wicg.github.io/feature-policy/#reporting


So I'm back to my question: is this an API we actually want to 
implement?  It seems like a fair amount of complexity and overhead and 
the one use case so far is for sites to have telemetry for when they're 
ending up with feature policy violations, right?


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


Re: Intent to implement: Reporting API

2018-11-14 Thread Boris Zbarsky

On 11/13/18 4:33 AM, Andrea Marchesini wrote:

I decided to implement this API, because it is required in the
web-platform-tests for FeaturePolicy.


Is it needed for any other reason?  If not, this seems like a bug in the 
tests: they should not be coupling the two specs together.


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


Re: Intent to implement and ship: img decode API support

2018-11-07 Thread Boris Zbarsky

On 11/7/18 11:15 AM, Andrew Osmond wrote:

This is simply a
new method for JS on image elements, so it should be unavailable.


Script can run in sandboxed iframes, depending on sandboxing flags.

It sounds like this feature is enabled by default in sandboxed iframes, 
as long as script is enabled, right?


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


Re: PSA: searchfox now indexing Windows Rust/C++ code

2018-11-02 Thread Boris Zbarsky

On 11/2/18 11:32 AM, Kartikaya Gupta wrote:

Those of you working in Windows-only Rust and C++ code will probably
be happy to hear that as of today searchfox is indexing the
Windows-only bits of our codebase as well.


This is awesome.  Thank you!

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


Re: web-platform-tests that fail only in Firefox (from wpt.fyi data)

2018-10-19 Thread Boris Zbarsky

On 10/19/18 8:42 AM, Philip Jägenstedt wrote:

That's a bit odd, the  is in the markup and would be
when running manually or under automation. Are you sure that explains
the difference?


Yes.  I filed https://github.com/web-platform-tests/wpt/issues/13625

-Boris

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


Re: Intent to implement: Dynamic module imports (JS 'import()' syntax)

2018-10-18 Thread Boris Zbarsky

On 10/18/18 10:45 AM, Jon Coppeard wrote:

DevTools bug: I don't know whether there is DevTools work to do here or not..


I can think of several devtools things that would be nice to have:

1) A log of which modules got loaded (and when?)
2) Ability to break in a module once it gets loaded but before its code 
starts to run (maybe this already works like for normal scripts?).
3) Ability to see the resulting module dependency graph (applies to 
static modules too).


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


Re: web-platform-tests that fail only in Firefox (from wpt.fyi data)

2018-10-17 Thread Boris Zbarsky

On 10/13/18 3:27 AM, Philip Jägenstedt wrote:

Fiddling with these rules can reveal lots
more potential issues, and if you like I could provide reports on that too.


I would be pretty interested in that, yes.  In particular, a report 
where there is 1 "not PASS and not FAIL" and 3 "PASS" would be pretty 
helpful, I suspect.


By the way, I recently found some tests that fail when run directly but 
pass in the harness.  :(  For example 
http://w3c-test.org/html/infrastructure/common-dom-interfaces/collections/htmlallcollection.html 
fails various subtests in all browsers due to the  being 
in the DOM when running directly.  Not really sure what we can do with that.


-Boris

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


Re: Intent to implement and ship: HTMLMarqueeElement

2018-10-12 Thread Boris Zbarsky

On 10/12/18 1:56 PM, Brian Grinstead wrote:

Summary: Motion is a key component of modern web design, and  is the 
premier...


Fire.  The premier fire so we can have fire and motion [1].

Or maybe it's just a dumpster fire?  ;)

The proposed change looks great to me.

-Boris

[1] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: web-platform-tests that fail only in Firefox (from wpt.fyi data)

2018-10-11 Thread Boris Zbarsky
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1498357 to track 
these failures.


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


Re: web-platform-tests that fail only in Firefox (from wpt.fyi data)

2018-10-11 Thread Boris Zbarsky

On 10/11/18 4:22 PM, Philip Jägenstedt wrote:

https://gist.github.com/foolip/a77c88e62aa3cfc461c2879f3e5d4855 is a
list of tests that fail in Firefox Nightly, but pass in stable
versions of Chrome, Edge and Safari.


Or more precisely have some sub-test that has that property, right?

Thank you for putting this list together.

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


Re: Intent to implement and ship: WebP image support

2018-10-11 Thread Boris Zbarsky

On 10/11/18 11:43 AM, Andrew Osmond wrote:

We are facing a growing number of webcompat reports against our Gecko-derived
Android offerings, where web developers assume Android and/or mobile
implies support for WebP.


In the past, I believe we objected to adding WebP for various reasons. 
Do we feel that those reasons are now outweighed by the compat problems?


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


  1   2   3   4   5   6   7   8   9   10   >