Intent to ship: unprefixed appearance property

[Cameron McCormack]

I intend to land bug 1620467 tomorrow, which implements the unprefixed 
appearance property and removes many non-standard values of -moz-appearance.

Intent to Prototype mail: 
https://groups.google.com/g/mozilla.dev.platform/c/nlun5QV63Bo/m/xUXCmySGAgAJ

The only things that have changed since that mail of a couple of weeks ago are:

* Chrome M84, which equivalent changes, has now reached Beta.
* Chrome goes one step further and makes `appearance: button` be treated like 
`auto`, rather than having an effect on all elements except a few.  The 
telemetry I gathered for this showed a low number of pages would be affected by 
this.  I plan to make this change only once the corresponding Chrome change has 
made it to release and has been proven to not need backing out.  This is 
tracked in https://github.com/w3c/csswg-drafts/issues/5174 and 
https://bugzilla.mozilla.org/show_bug.cgi?id=1652899.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to prototype: unprefixed appearance property

[Cameron McCormack]

Summary:

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

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

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

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

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

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

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

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

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

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

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

to

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

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

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

to

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


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

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

Platform coverage: all

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

DevTools bug: none

Other browsers:

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

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

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

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

Re: Intent to ship: a change to the initial value of image-orientation

[Cameron McCormack]

On Mon, Feb 17, 2020, at 8:19 AM, Cameron McCormack wrote:
> This doesn't really fit the format of an Intent email, but just as a 
> heads up, I am landing a change to the initial value of the 
> image-orientation property, from "none" to "from-image".  The effect of 
> this change is that EXIF orientation data in JPEG images used in HTML 
>  elements and in the CSS content property will be honored by 
> default.

This work was delayed a little, but has just landed and is now in the current 
Nightly.  Now, all uses of JPEG images with EXIF orientation metadata will be 
automatically oriented correctly, except for content images with 
`image-orientation: none`.  Some of the upstream HTML spec issues still need 
discussion but I didn't feel they needed to block this landing.

The equivalent change shipped in Chrome 81 on April 7.

If you see any odd image orientation or sizing behavior, please let me know.

Thanks,

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

Re: Intent to unship: FTP protocol implementation

[Cameron McCormack]

If you plan to time the unshipping of our FTP support to be after Chrome 81, 
then please be aware that Chrome releases are currently paused on Chrome 80.

https://chromereleases.googleblog.com/2020/03/upcoming-chrome-and-chrome-os-releases.html

On Thu, Mar 19, 2020, at 8:56 PM, Michal Novotny wrote:
> According to [1], it will be turned off for all users in 81. In 80 it 
> will be turned off for 1% of users.
> 
> [1] 
> https://docs.google.com/document/d/1JUra5HnsbR_xmtQctkb2iVxRPuhPWhMB5M_zpbuGxTY/edit#heading=h.a4pkgy626xf3
> 
> 
> On 3/19/20 9:02 AM, Henri Sivonen wrote:
> > On Thu, Mar 19, 2020 at 2:24 AM Michal Novotny  
> > wrote:
> >> We plan to remove FTP protocol implementation from our code.
> > 
> > Chrome's status dashboard says "deprecated" and
> > https://textslashplain.com/2019/11/04/bye-ftp-support-is-going-away/
> > said the plan was to turn FTP off by default in version 80. Yet, I
> > just successfully loaded ftp://ftp.funet.fi in Chrome 80 on Mac and in
> > Edge 82 (Canary) on Windows 10, and I'm certain I haven't touched the
> > flag in either. (The location bar kept showing the ftp:// URL, so it
> > doesn't appear to be a case of automatically trying HTTP.)
> > 
> > Do we know why Chrome didn't proceed as planned? Do we know what their
> > current plan is?
> > 
> > Do we know if Edge intends to track Chrome on this feature or to make
> > an effort to patch a different outcome?
> > 
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Land your tests for now-public security bugs

[Cameron McCormack]

On Tue, Mar 10, 2020, at 10:33 AM, Daniel Veditz wrote:
> We need to do better at the remembering-to-land part. If you've fixed a 
> security
> bug in the past please check if you have any hanging *in-testsuite?* bugs
> for bugs that are now public.

Thank you for the reminder.  (I've got tests going back six years I need to 
land!)

Can we have the bots that operate on Bugzilla needinfo bug assignees when a bug 
is opened up and has an "in-testsuite?" flag?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: a change to the initial value of image-orientation

[Cameron McCormack]

On Mon, Feb 17, 2020, at 9:12 PM, Anne van Kesteren wrote:
> Where is this standardized?

https://drafts.csswg.org/css-images-3/#the-image-orientation

> See https://github.com/whatwg/html/issues/4495 for some tricky questions
> that come up that haven't been conclusively answered yet, as far as I
> can tell.

Thanks, I wasn't subscribed to that issue.  I don't think all questions 
mentioned there necessarily need to block this change.  I will respond there.

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

Intent to ship: a change to the initial value of image-orientation

[Cameron McCormack]

This doesn't really fit the format of an Intent email, but just as a heads up, 
I am landing a change to the initial value of the image-orientation property, 
from "none" to "from-image".  The effect of this change is that EXIF 
orientation data in JPEG images used in HTML  elements and in the CSS 
content property will be honored by default.

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

This change has been timed to land so that it reaches the first Firefox release 
after the Chrome release that also makes this change.  This has also already 
landed in WebKit.

If you notice any problems due to images being unexpectedly rotated, please 
file a bug and let me know.

Thanks,

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

Re: Intent to ship: CSS subgrid

[Cameron McCormack]

On Fri, Oct 18, 2019, at 9:31 AM, ikilpatr...@chromium.org wrote:
> I'd argue that the color example is a "trivial" feature, unlike 
> subgrid. But the original framer of the policy would have a better 
> understanding of what that meant.
> 
> FWIW most new CSS features are placed behind values/etc, so I don't 
> believe that is the distinction in the policy.

That's true.  And I agree it is not "trivial".  The policy is (rightly) vague 
so we can make a judgement call, though I would probably side with others in 
thinking that this is an extension of an existing feature.

But I think we've ended up with practical considerations dictating whether we 
restrict a given CSS feature to secure contexts.  I have some half written 
patches from a couple of years ago to add support in Gecko for hiding 
individual properties (though not values) behind a secure context flag.  I ran 
into the issues that Emilio mentioned, where it affects shorthand serialization 
in a way that is not as easy to handle as pref-controlled properties, and would 
result in additional state propagated down onto declaration objects.  Far from 
impossible to handle, but it made us stop and think whether it was worth it.

If I remember correctly, when the issue of gating CSS features behind secure 
contexts was brought up in the CSS Working Group last, the response was tepid.

So at this point I wonder whether it is worth trying to restrict features at 
the CSS syntax level.  Secure context restrictions are a kind of best effort 
thing to help encourage authors to switch to https, and it's not necessary for 
100% of new features to be restricted to achieve that.  Unlike Web IDL defined 
features, where it's easy to drop in [SecureContext] in the spec and in our 
implementations, there is some work involved here to restrict CSS properties or 
values.  If other vendors are willing to add the ability to make CSS properties 
and values be unavailable in secure contexts to their engines, then I can 
resurrect my patches.  But if that's not likely to happen, I think it's 
probably best to concentrate our restriction efforts on DOM APIs, where I 
believe it's still the right thing to do.  (Including for Paint API.)

I'm curious to hear if others think differently.

Thanks for raising this Ian, and I hope we can clarify our policy as a result 
of this discussion.

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

Re: Intent to unship SVGZoomAndPan interface

[Cameron McCormack]

On Sun, Sep 29, 2019, at 1:22 PM, Boris Zbarsky wrote:
> 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?

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

It would be good to have a historical test to ensure the property is gone, too, 
not just the SVGZoomAndPan interface.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What to do about scroll anchoring?

[Cameron McCormack]

How useful is scroll anchoring outside of the two cases mentioned in 
https://drafts.csswg.org/css-scroll-anchoring/#intro i.e. images loading and ad 
iframes being inserted?  Would it be feasible to make scroll anchoring a much 
less general mechanism, and to scope it down to handling these specific cases?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship SVGZoomAndPan interface

[Cameron McCormack]

On Sat, Sep 28, 2019, at 11:41 PM, longs...@gmail.com wrote:
> In [1] I intend to unship the SVGZoomAndPan interface. The SVG WG 
> decided to remove this interface in [2] as it's either not implemented 
> at all or does nothing in current implementations. Our implementation 
> is currently the "does nothing" kind i.e. you can get and set the 
> property but it there's no functionality beyond that.

Sounds good, thanks Robert.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intend to deprecate: XLink attributes on MathML elements

[Cameron McCormack]

On Sat, Aug 24, 2019, at 8:31 PM, Frédéric Wang wrote:
> In bug 1548524, I intend to deprecate XLink attributes (“href”, “type”,
> “show” and “actuate”) on MathML elements. This has never been supported
> by other browsers and AFAIK there is not any plan to do so. Gecko
> actually only has partial support for XLink and there is no plan to
> implement full support [1].
>
> [...]
>
> For now these attributes
> will only be disabled in nightly and a use counter will be introduced to
> determine how much this feature is used.

Thank you for cleaning this up, Frédéric.  What are the use counter thresholds 
you are looking for with these MathML deprecations?  A certain percentage of 
all pages, or of pages with any MathML?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NS_NewURI is now thread-safe

[Cameron McCormack]

This is going to let us simplify a whole lot of URL handling code in the style 
system, where we otherwise have to store strings and lazily creating nsIURIs 
when we're back on the main thread.  Thanks so much!

On Mon, Jun 10, 2019, at 1:08 PM, Valentin Gosu wrote:
> Hello everyone,
> 
> nsIURI has been immutable for a few releases now, meaning once you had one
> it was safe to use it on any thread (even change it using nsIURIMutator).
> But until recently you couldn't create a new URI off the main thread
> (unless you already knew the type of the URI).
> A few days ago I closed bug 922464
> , which means nsIURI
> can now be safely used and created on any thread via NS_NewURI. It also
> means nsIProtocolHandler.newURI no longer exists, and if you want to add
> any other special scheme to Gecko you should do so in NS_NewURI in
> nsNetUtil.cpp
> 
> Most of the work happened in bug 1536744
> . This unblocks work
> to make make nsIPrincipal thread safe in bug 1443925
> .
> I've noticed there are some places that keep URIs around as strings. If
> those strings are regularly used to create nsIURIs, I strongly encourage
> you to do so from the beginning.
> 
> There is still work to be done in order to reduce the number of
> implementations we have for nsIURI and resolve our incompatibilities with
> the URL spec. Stay tuned.
> 
> Let me know if you uncover any issues, or if you have any questions.
> 
> Cheers!
> -- 
> Valentin
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: hasFeature() method on some SVG elements

[墨俊凱 / Cameron McCormack]

On Fri, May 3, 2019, at 8:31 PM, Christopher Mills wrote:
> On Fri, May 3, 2019 at 3:38 AM Cameron McCormack  wrote:
>> The hasFeature() method on some SVG elements comes from SVG 1.0 and was 
>> intended to be used as part of SVG's extension mechanisms. This function 
>> never returned anything other than false in browser implementations, and was 
>> removed in SVG 2. Chrome no longer supports this, although WebKit still 
>> does. I don't anticipate any issue removing this.
>> 
>>  The removal is being done in 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1133175.
> 
> The referenced bug references SVGTests.hasExtension; what's the correct one? 

The method is defined on SVGTests, which is a mixin interface implemented by 
some specific SVG element interfaces (like SVGGraphicsElement).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: hasFeature() method on some SVG elements

[Cameron McCormack]

The hasFeature() method on some SVG elements comes from SVG 1.0 and was 
intended to be used as part of SVG's extension mechanisms.  This function never 
returned anything other than false in browser implementations, and was removed 
in SVG 2.  Chrome no longer supports this, although WebKit still does.  I don't 
anticipate any issue removing this.

The removal is being done in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1133175.

Thanks,

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

Re: nsIPresShell has gone

[Cameron McCormack]

On Fri, May 3, 2019, at 11:44 AM, Masayuki Nakano wrote:
> Finally, I completely got rid of nsIPresShell from our tree.
> https://bugzilla.mozilla.org/show_bug.cgi?id=253889

Thank you for doing this, Masayuki!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

[Cameron McCormack]

On Thu, Apr 25, 2019, at 7:55 PM, Gijs Kruitbosch wrote:
> Ideally, I think the debugging usecase would be better served by a more 
> barebones "here's a docshell that will load arbitrary content off our 
> trusted localhost server in 1 process" type app than by making desktop 
> firefox run these tests, but perhaps it's not worth our time to make 
> such a thing...

We have `mach run -layoutdebug ` which will load a document from any host 
in the content process. I'm not sure how easy it would be to be able to load 
mochitests in this environment (although you could probably kick off a real 
mochitest single test run, leave it open, then run the layout debugger pointing 
to mochi.test), but for most of my single process debugging needs the layout 
debugger works well.
___
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

[Cameron McCormack]

On Tue, Apr 9, 2019, at 1:56 PM, Cameron McCormack wrote:
> You should exclude layout/reftests/w3c-received/ too.

layout/reftests/w3c-css/received/
___
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

[Cameron McCormack]

On Tue, Apr 9, 2019, at 1:39 PM, Brian Grinstead wrote:
> I'd like to rewrite markup in the tree to avoid using the [type] 
> attribute on 

Re: SVG text coordinate systems

[Cameron McCormack]

Hi Alex,

On Tue, Apr 2, 2019, at 1:47 AM, Alex Henrie wrote:
> Hi, I am trying to fix Bug 1529182,[1] but debugging the SVG 
> code is particularly difficult for me because it uses at least six
> coordinate spaces, and I can't figure out how they relate to each
> other:
> 
> - Run space
> - Run user space
> - Frame user space
> - (Regular?) user space
> - GFX space
> - App space
> 
> Can anyone here explain them to me?

Using this as an example:

  
  
abcd
  

the frame tree dump might look like this (with some unnecessary information 
elided):

  SVGOuterSVG(svg)(0) {0,0,24000,18000}
SVGOuterSVGAnonChild(svg)(0) {0,0,0,0}
  SVGText(text)(1) {5985,4875,8190,1410}
Block(text)(1) {0,0,2880,1440}
  line 7f2768ba20a8: count=2 {0,0,2880,1440}
Text(0)"ab" {0,30,1440,1380}
Inline(tspan)(1) {1440,30,1440,1380}
  Text(0)"cd" {0,0,1440,1380}

The curly braces are the mRect values for each frame, which are in app units, 
which are 1/60 of a CSS pixel.

SVGTextFrame works by leveraging the existing support for CSS rendering of 
blocks and inlines by building an nsBlockFrame for the  contents, 
nsInlineFrame for any , and nsTextFrame for text nodes.  This lets us 
avoid re-implementing text layout in the SVG code.  Anything SVG specific, like 
text positioning attributes or , are handled as a post-processing 
step when determining where to render each bit of the resulting CSS-positioned 
nsTextFrames.

Generally these mRects are relative to their parent, but the nsBlockFrame child 
of the SVGTextFrame is used just to lay out the text and is not rendered 
directly, so its (0, 0) position doesn't mean much.  Its width and height (2880 
x 1440 app units) are the result of reflowing it without any constraints on its 
size.  The layout of the block frame and its descendants is done independent of 
any SVG text positioning attributes and .

Because we leverage standard HTML/CSS rendering for SVG text, and because SVG 
text positioning attributes and s can affect the positions (and 
rotations) of individual glyphs, we produce TextRenderedRun objects to 
represent each contiguous sequence of characters within an nsTextFrame that we 
can ask the text frame to render in one go.  In this example, we end up 
producing three TextRenderedRuns:

* One for "a", at SVG text position (100, 100).  This covers {0,0,720,1380} of 
the first nsTextFrame.
* One for "b", at SVG text position (200, 200).  This covers {720,0,720,1380} 
of the first nsTextFrame.
* One for "cd", at SVG text position (200 + advance_in_user_units("b"), 200).  
This corresponds to the entire {0,0,1440,1380} of the second nsTextFrame.

Those rectangles might be in what you call "run space".  I don't think they're 
really named in the code.

In SVGTextFrame::PaintSVG, as we iterate over each TextRenderedRun, we need to 
set a transform on the gfxContext so that when asking an nsTextFrame to render 
some of its characters (the substring corresponding to the TextRenderedRun), it 
will appear in the right place.  Most of the complication in SVGTextFrame.cpp 
is doing this.

As for the coordinate systems you mention:

User space is the local SVG coordinate system for an SVG element.  In this 
example, the user space of the  element is the coordinate system the 
 establishes, with (0, 0) at the top level of the  element on the 
page, and (400, 300) at the bottom right.

"Run user space" is a term I made up to mean a coordinate space that is the 
same as the 's user space except translated so that the origin is at the 
top left of the rectangle that covers a given TextRenderedRun, and rotated by 
the TextRenderedRun's rotation.  This example doesn't have any rotate="" 
attributes or s, so there's no rotation here.  So in this coordinate 
system, (0, 0) is at the top left of the "b" glyph cell, and (12, 23) is at the 
bottom right of the "b" glyph cell.  TextRenderedRun::GetRunUserSpaceRect 
returns {0,0,12,23}, and TextRenderedRun::GetUserSpaceRect returns something 
like {200,86,12,23}, depending on the ascent/descent of the "b" (since the SVG 
text positioning aligns its alphabetic baseline at y=100).

"Frame user space" is something that doesn't really correspond to what you see 
on the page.  It's similar to "run user space": it's a coordinate system of the 
same scale as the 's user space, but with its origin placed at the top 
left corner of an nsTextFrame's rectangle.  For "b", 
TextRenderedRun::GetFrameUserSpaceRect returns {12,0,12,23} -- it's the same as 
GetRunUserSpaceRect but translated to where in its corresponding nsTextFrame is.

I'm not sure about "GFX space" and "app space" as terms.  There are many 
different units the coordinate values could be in -- see layout/base/Units.h.  
In SVG PaintSVG methods (e.g. SVGGeometryFrame::PaintSVG), setting `aTransform 
* aContext.CurrentMatrixDouble()` as the current matrix on the context will 
allow you to paint things in the current SVG element's 

MOZ_DBG

[Cameron McCormack]

Lately I've been finding Rust's dbg!() macro[1] useful for quick debugging.  
Its main usefulness is in avoiding the need to extract out an expression into a 
separate variable just so that you can print out its value and then use the 
value in its original context.

I wanted something similar for C++, so in bug 1538081, which just landed on 
autoland, I've added the MOZ_DBG macro.

MOZ_DBG can be added around almost any kind of expression[2], as long as there 
is an operator<<(ostream&, ...) defined for its type.  I added operator<< 
definitions for nsAString, nsACString, mozilla::Span, nsTArray, mozilla::Array, 
and T[N], since they seemed useful.  And as a special case, if you wrap MOZ_DBG 
around a pointer value, then it will use the operator<< of the dereferenced 
object (if the operator<< exists, and the pointer is non-null), and otherwise 
just prints out the pointer value.  The output goes to stderr.

The macro is defined in mfbt/DbgMacro.h, but I've included it into nsDebug.h, 
so that it should be available in most files without needing to explicitly 
#include .  It's available in non-DEBUG builds, but not in 
MOZILLA_OFFICIAL builds.

Example:

  nsTArray numbers;
  MOZ_DBG(numbers = { MOZ_DBG(123 * 1), MOZ_DBG(123 * 2) });
  MOZ_DBG(numbers[MOZ_DBG(numbers.Length() - 1)]);
  MOZ_DBG(numbers) = { 789 };
  MOZ_DBG(numbers);

Output:

  [/path/to/file.cpp:319] 123 * 1 = 123
  [/path/to/file.cpp:319] 123 * 2 = 246
  [/path/to/file.cpp:319] numbers = { MOZ_DBG(123 * 1), MOZ_DBG(123 * 2) } = 
[123, 246]
  [/path/to/file.cpp:320] numbers.Length() - 1 = 1
  [/path/to/file.cpp:320] numbers[MOZ_DBG(numbers.Length() - 1)] = 246
  [/path/to/file.cpp:321] numbers = [123, 246]
  [/path/to/file.cpp:322] numbers = [789]

There is also a macro MOZ_DEFINE_DBG, which can be used to define an operator<< 
for a class.  It's like a poor imitation of #[derive(Debug)].

Example:

  struct Point {
int x;
int y;

MOZ_DEFINE_DBG(Point, x, y)
  };

  Point p{10, 20};
  MOZ_DBG(p);

Output:

  [/path/to/file.cpp:100] p = Point { x = 10, y = 20 }


[1] https://doc.rust-lang.org/stable/std/macro.dbg.html
[2] One specific case where it won't work is if you are wrapping it around a 
prvalue being used to initialize an object, and the type of that value is 
something that doesn't have a copy or move constructor available.  Such types 
should be rare, though, and you'll get a compiler error if you try.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Where to put timeout test?

[Cameron McCormack]

On Wed, Mar 6, 2019, at 5:05 PM, violet.bugrep...@gmail.com wrote:
> However, both the reviewer and me don't know how to put a timeout test. 
> It won't crash in any case, so it's not a crash test. But the mochitest 
> can only be used to check JavaScript assertion, if I use mochitest, the 
> test utility will hang waiting for JavaScript stuff, then eventually 
> timeout because there is nothing to assert.
> 
> Where to put a testcase like this?

You can use a crashtest for this under layout/svg/crashtests/.  crashtests are 
like reftests that don't actually check against a reference, but will just fail 
if the test crashes, or causes some assertions, or times out.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: -webkit-line-clamp

[Cameron McCormack]

Summary:

-webkit-line-clamp is a feature implemented in WebKit, Blink, and Edge that 
allows authors to control the height of a block so that it contains at most the 
specified number of lines, and if there are excess lines, an ellipsis is 
inserted in the last non-excess line.

http://dropshado.ws/post/1015351370/webkit-line-clamp

Lack of support for -webkit-line-clamp is a common cause of Web compatibility 
problems in Gecko, particularly on mobile sites.  Unfortunately, this feature 
is an odd duck in the existing implementations, since:

1. It only has an effect in `display: -webkit-box` and `display: 
-webkit-inline-box` elements.
2. Any excess lines are still displayed, and overflow the box.  Authors must 
(and do) use `overflow: hidden` to hide them.
3. -webkit-line-clamp is implemented as an additional constraint on the 
intrinsic size of the element (like a max-block-size property), and so usually 
only has an effect if `-webkit-box-orient: vertical` is also specified.

The CSS Working Group is attempting to define a standards-based solution that 
is sufficiently compatible with existing content.  As currently written, I 
think the standard line-clamp property (if we also support it with the -webkit 
prefix) should be compatible with the content we know we are currently broken 
on, although there is some risk of breakage due to the property applying to 
more elements.  This solution would need a more complex solution than 
WebKit/Blink currently have, however.  (Rather than just adjusting an input to 
the intrinsic sizing of the element, it would require fragmenting the excess 
lines away and suppressing them, something we don't have the concept for 
internally at the moment.)  The current spec does capture the use case of just 
limiting the number of lines in an element more sensibly than the existing 
implementations, though.

My current plan is to implement something closer to the existing 
implementations since (a) it is simpler, and (b) there is less risk of 
compatibility problems introduced by -webkit-line-clamp applying to more 
elements than in WebKit/Blink.  I will then provide feedback on the spec to 
support this behavior, or if that's not possible, get something added to the 
Compat spec.  Implementing the full fragmentation based line-clamp solution can 
be a followup task at some point.

Note that there seems to be some desire in Blink to replace 
-webkit-line-clamp's behavior with something that lives in a spec 
(https://bugs.chromium.org/p/chromium/issues/detail?id=305376) but I am 
doubtful that support for it can be removed entirely.


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

Link to standard: https://drafts.csswg.org/css-overflow-3/#line-clamp

Platform coverage: everywhere

Estimated or target release: Firefox 68

Preference behind which this will be implemented: 
layout.css.webkit-line-clamp.enabled

Is this feature enabled by default in sandboxed iframes? yes

DevTools bug: as this is being implemented only for compatibility I don't think 
it's appropriate to build a DevTools feature for it
Do other browser engines implement this? yes (WebKit, Blink, and Edge)

web-platform-tests: none exist (and I don't plan to write WPTs until I manage 
to get the spec changes made)

Is this feature restricted to secure contexts? no (other engines don't restrict 
it)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: -moz-binding CSS property from content.

[Cameron McCormack]

On Thu, Jan 31, 2019, at 8:03 AM, Emilio Cobos Álvarez wrote:
> In bug 1523712 I intend to unship the `-moz-binding` CSS property from
> content pages.

Sounds good to me, thanks!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: SVG Working Group

[Cameron McCormack]

On Thu, Jan 10, 2019, at 12:38 AM, Henri Sivonen wrote:
> A (non-changed) part of the charter says under SVG2: "This
> specification updates SVG 1.1 to include HTML5-compatible parsing". Is
> that in reference to
> https://svgwg.org/svg2-draft/single-page.html#embedded-HTMLElements or
> something else? I.e. does it mean the SVG WG wants to change the HTML
> parsing algorithm to put  and  with
> non-integration-point SVG parent into the HTML namespace in the HTML
> parser?

I see the note in that section you link that says:

> Currently, within an SVG subtree, these tagnames are not recognized by the 
> HTML parser to
> be HTML-namespaced elements, although this may change in the future. 
> Therefore, in order
> to include these elements within SVG, one of the following must be used:
> ...

The "this may change in the future" part sounds like someone thought that it 
might be the case in the future.  Saying that SVG 2 "includes HTML5-compatible 
parsing" is a bit odd, though, since that behavior is defined in the HTML spec. 
 In any case, given the group's intended focus on stabilizing and documenting 
what is currently implemented and interoperable, I doubt that making such a 
change would be in scope.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: SVG Working Group

[Cameron McCormack]

On Mon, Dec 24, 2018, at 4:59 AM, L. David Baron wrote:
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it. Given our past involvement, we should
> probably have some comment, even if it's simply in support.

A few high level comments (I only looked at sections 1 and 2):

The stated primary focus of the charter period is stabilization and testing, 
and I think this is the right thing to spend most of the time on, so we should 
support this charter for this.

The stated secondary focus is new graphical features if they have broad 
consensus. I agree that any such work needs broad consensus so that we don't 
end up with features with few or no implementations. Since that has been a 
problem in the past, I would prefer something be said explicitly about 
consensus from implementors here.

The Core SVG document mentioned in the Deliverables section is new and is 
intended to define a subset that is used in OpenType SVG glyphs and potentially 
other places. I'm fine with working on this, although I question whether it 
duplicates or replaces some of the work done as part of the SVG Integration 
spec (which did not progress beyond a WD). So clarification on the relationship 
to that spec might be good.

In section 1. Scope it says "The SVG WG develops a single deliverable, the SVG 
specification" but in section 2. Deliverables, multiple specifications are 
mentioned. These seem in conflict.

No particular comment on how realistic the target publication dates are, since 
I haven't been paying attention recently to the group's work to know how 
accurate they are.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nasm will soon become a build dependency

[Cameron McCormack]

On Fri, Dec 21, 2018, at 3:17 PM, Martin Thomson wrote:
> The OP said >= 2.10. But you appear to have that. 

Oh, missed that.

I just tried building some other versions of nasm from source (since 2.11 is 
the latest packaged in my distribution) and 2.13 was the earliest that I could 
build with.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nasm will soon become a build dependency

[Cameron McCormack]

On Fri, Dec 21, 2018, at 11:05 AM, Thomas Daede wrote:
> nasm is now required for building on Linux.

Is there a minimum version required?  I am getting errors like this building:

/z/moz/g/third_party/dav1d/src/x86/ipred_ssse3.asm:42: error: operand 1: 
expression is not simple or relocatable

$ nasm -v
NASM version 2.11.08
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Bypassing about:home/privacy page loads on new test profile builds via mach

[Cameron McCormack]

On Tue, Oct 23, 2018, at 9:53 AM, Kyle Machulis wrote:
> Adding the following prefs turns off all new profile about:home loads
> and just starts the browser with about:blank:
> 
> [runprefs]
> browser.startup.blankWindow=true
> browser.newtabpage.enabled=false
> browser.startup.firstrunSkipsHomepage=true
> browser.startup.homepage=about:blank
> datareporting.policy.dataSubmissionPolicyBypassNotification=true

This is great, thanks for the tip Kyle!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

[Cameron McCormack]

On Thu, Sep 20, 2018, at 1:52 AM, Ehsan Akhgari wrote:
> While it may be the case that we may need to be more stable for
> MOZ_RELEASE_ASSERTs, I very much doubt that every single MOZ_ASSERT in our
> codebase is actually a guaranteed to never fail, so promoting them all to
> be enabled in something like Nightly is extremely dangerous in terms of the
> stability of Nightly for users who are trying to use the browser to get
> their normal work done.

If it's truly useful to know whether Nightly users are failing these MOZ_ASSERT 
assertions, we could use Telemetry to report their failure instead of crashing.

(I wonder if we could collect all the same data, and use the same crash 
reporting infrastructure, for non-crashing crash reports like this.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CSS Scroll Snap Level 1

[Cameron McCormack]

On Wed, Sep 5, 2018, at 7:30 PM, Chris Mills wrote:
> https://drafts.csswg.org/css-scroll-snap-1/ 
> 
> 
> Have we got any current or future plans for implementing this in Gecko?

Yes, we have an implementation of an earlier draft for this feature, which 
shipped in early 2015.  The Layout team has on our roadmap for Q4 to update the 
implementation to the current spec.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Layout Bugzilla components

[Cameron McCormack]

[bcc: firefox-dev, firefox-triage-leads]

Hi,

The Layout team has done some Bugzilla component reorganization to distribute 
features and areas of code a bit better.  There are a number of new components 
split out from existing ones:

* Previously covered by CSS Parsing and Computation:
** CSS Transitions and Animations

* Previously covered by the general Layout component:
** Layout: Columns
** Layout: Flexbox
** Layout: Generated Content, Lists, and Counters
** Layout: Grid
** Layout: Ruby
** Layout: Scrolling and Overflow

Some lesser used components have been merged into other components:

* Layout: HTML Frames => Layout: Images (which is renamed; see below)
* Layout: Misc Code => Layout
* Layout: View Rendering => Layout: Web Painting

And a couple of components have been renamed:

* Layout: Images -> Layout: Images, Video, and HTML Frames
* Layout: R & A Pos -> Layout: Positioned
* Layout: Text -> Layout: Text and Fonts

Also, the descriptions for all of these components have been updated, and now 
include a list of specifications they are intended to cover.

Hopefully this makes it easier for developers to watch for bugs related to 
features they are interested in, and for bug filers to find the right component 
to file their bugs in.

Note that apart from the components that were merged, I haven't asked for 
existing bugs to be moved from their old components to their new, more 
specialized components.  I will leave it to the new triage leads for individual 
components to decide which bugs to move across if any.

Please check the Bugzilla components you are watching and whether you need to 
update any bookmarked search or bug filing URLs.

Thanks,

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

PSA: static atom definitions have moved to xpcom/ds/StaticAtoms.py

[Cameron McCormack]

Hi everyone,

Just a heads up on some changes to static atoms that I landed a couple of days.

Static atom definitions now live in xpcom/ds/StaticAtoms.py.  This script 
generates nsGkAtomList.h at build time.  nsGkAtomList.h is still used by 
nsGkAtoms.{h,cpp} to actually define the C++ atoms and by 
servo/components/style/gecko/regen_atoms.py to generate Rust definitions that 
link to the C++ ones.  (The move to defining these in Python will help with 
later work simplifying regen_atoms.py and generating additional data to help 
reference static atoms from Rust static consts.)

nsGkAtoms is now the only static atom table we have.  Previously we had 
separately defined atoms in nsCSSPseudoElements, nsCSSAnonBoxes, and 
nsDirectoryService.  These have all been merged into nsGkAtoms with prefixes on 
the identifiers, e.g. nsGkAtoms::PseudoElement_before.  For convenience, 
accessors on nsCSSPseudoElements and nsCSSAnonBoxes to their atoms remain, but 
they've become inline accessor functions, e.g. nsCSSPseudoElements::before().

If defining a new pseudo-element or anonymous box, you'll need to add an entry 
to both nsCSS{PseudoElement,AnonBox}List.h and StaticAtoms.py.  Assertions 
check for this.

Thanks,

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

Re: Intent to implement: Visual Viewport API

[Cameron McCormack]

On Tue, Jul 24, 2018, at 12:22 PM, Boris Zbarsky wrote:
> On 7/23/18 7:36 PM, Tanushree Podder wrote:
> > Secure contexts: Yes
> 
> I'm not sure what this line means here.

I updated the intent to implement template at 
https://wiki.mozilla.org/ExposureGuidelines#Intent_to_implement to make it 
clearer what this is asking.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

[Cameron McCormack]

On Fri, Jul 13, 2018, at 6:51 AM, Kris Maglione wrote:
> I actually have a patch sitting around with helpers to make it super easy to 
> use smart pointers as tagged pointers :) I never wound up putting it up for 
> review, since my original use case went away, but it you can think of any 
> specific cases where it would be useful, I'd be happy to try and get it 
> landed.

Speaking of tagged pointers, I've used lower one or two bits for tagging a 
number of times, but I've never tried packing things into the high bits of a 64 
bit pointer.  Is that inadvisable for any reason?  How many bits can I use, 
given the 64 bit platforms we need to support?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: explicit values in image-orientation

[Cameron McCormack]

https://drafts.csswg.org/css-images-3/#the-image-orientation

The CSS image-orientation property allows an author to control whether an image 
(in an  or generated content) is automatically rotated and flipped 
according to the EXIF data in the image.  Originally, the specification only 
allowed explicit multiple-of-90°  values (and a flip keyword).  When we 
implemented image-orientation, we supported explicit angle values as well as a 
keyword to take the orientation from the image itself.

The specification now deprecates the explicit angle values.  Since Firefox is 
the only browser to implement this property, I am planning to remove support 
for the angle values, and file an issue on the spec to remove them entirely.

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

Re: Intent to Unship: -moz-is-resource-document media feature from content pages.

[Cameron McCormack]

On Fri, Jun 15, 2018, at 8:02 AM, Emilio Cobos Álvarez wrote:
> I expect no compat fallout whatsoever since it can only match, well, in 
> SVG resource documents, and it was meant to be an internal media feature 
> in the first place.

This is fine.  I expect approximately zero content relies on this.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is super-review still a thing?

[Cameron McCormack]

On Thu, Apr 26, 2018, at 12:41 AM, Mark Côté wrote:
> How we might use blocking reviewers in our workflow is still open, but 
> it could be used for training up reviewers, in which case the trainee 
> would be a regular reviewer and the module peer/owner would be a 
> blocking reviewer.

It's not uncommon for me to submit patches for review from multiple people 
where I require all reviewers to sign off on the patch, usually because I ask 
them to look at different parts of the patch.  I don't think I have ever sent a 
patch to get review from more than one person with the intention of landing it 
if only one person OKs it.  (I'd probably needinfo people to get that kind of 
feedback.)  So ignoring potential new workflows like the training one you 
mention, I think I would exclusively use blocking reviewers.  It's good to know 
that Phabricator will help me avoid accidentally landing patches when not all 
of my reviewers have signed off.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using WebIDL objects in XPIDL

[Cameron McCormack]

On Thu, Apr 19, 2018, at 1:19 PM, Nika Layzell wrote:
> This allows us to avoid using nsISupports to pass WebIDL objects which
> don't have corresponding XPIDL interfaces through XPIDL defined methods.

Thanks Nika, this is great!  Avoiding nsIDOMBlah interfaces in C++ was one of 
the reasons that prompted me recently to try converting some interfaces from 
XPIDL to Web IDL, so it's really nice that we can now avoid that awkwardness 
and also avoid the code size overhead that a conversion to Web IDL would cause.

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

Intent to unship: SVGSVGElement.{pixel, screenPixel}UnitToMillimeter{X, Y}

[Cameron McCormack]

In https://bugzilla.mozilla.org/show_bug.cgi?id=1133172 I plan to remove our 
implementations of these four IDL attributes on SVGSVGElement:

pixelUnitToMillimeterX
pixelUnitToMillimeterY
screenPixelUnitToMillimeterX
screenPixelUnitToMillimeterY

These were originally in SVG 1, but they never had much use, were never 
implemented in a way that was useful, and so were removed from SVG 2.  Chrome 
removed their implementation a couple of years ago, where they found they had 
"virtually zero usage".

Barring objections I will land the removal in 48 hours.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

[Cameron McCormack]

On Tue, Apr 10, 2018, at 11:58 AM, Jeff Gilbert wrote:
> Do we have a heuristic for when to /not/ include something from HTML in SVG?

If it doesn't make two features which already exist in both HTML and SVG more 
consistent, then I wouldn't include it.

> More or less, these additions to SVG just strike me as having solid
> potential risk (for both spec-interaction and implementation bugs) and
> negligible upside. Do we have people asking for this?

I don't know of people asking for this, but I would hope that we could share 
the implementations of these properties between HTMLAnchorElement and 
SVGAElement.  The closer the two  elements are in behavior, and the more we 
can share implementation between them, the lower the risk for bugs between the 
two.  (Ignoring the general risk of bugs from touching code at all.)

> Are there privacy concerns from embedding pings (et al) in images? I
> suppose we better have been handling CORS requests from within SVGs
> properly already, so it should Just Work?

SVG as images don't have scripting and can't be interacted with to activate 
links, so I don't think it's a concern there.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

[Cameron McCormack]

On Tue, Apr 10, 2018, at 7:56 AM, Jeff Gilbert wrote:
> Can we not put more things into SVG? Making SVG more complicated seems
> like it should be an anti-goal for the web platform.

I think we should align the features and behavior of HTML  and SVG .

  
  something
 
   
  

I don't see why the two DOM objects for the HTML  and SVG  should behave 
substantially differently.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Cameron McCormack]

On Fri, Mar 9, 2018, at 9:41 AM, Robert O'Callahan wrote:
> It might be worth measuring how that translates to installer code. One
> might hope that all that repetitive boilerplate code compresses well
> (or can be made to).
Testing my local bug 1341546 patches, I get a 59 KiB increase in
.tar.bz2 package size and 189 KiB increase in libxul.so, which does seem
a bit much for the ergonomic gains I was going for.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Cameron McCormack]

On Fri, Mar 9, 2018, at 8:41 AM, Bobby Holley wrote:
> The problem is precisely that it's gradual - a few kilobytes at a
> time, certainly nothing to trigger our alerts. Waiting for it all to
> pile up and then launching a herculean effort to move things _back_ to
> XPIDL would be a huge waste of time, which is why I'm trying to
> address the problem now.
How much effort would it be, and would it be worth it, to support Web
IDL argument conversion in a more dynamic way, like XPConnect does,
and then opt in to this for interfaces / methods we decide are not
performance critical?  (I'm guessing that it would be a fair amount
of effort.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

performing cross-context instanceof checks

[Cameron McCormack]

Hi,

For a long time Firefox's behaviour for instanceof checks on DOM objects, when 
the right-hand side interface object comes from a different window from the 
object on the left, has differed from other browsers.  For example,

  otherWindow.document instanceof Node

evaluates to true in Firefox and false in other browsers.

Recently, Web IDL has been updated to return false for cross-context instanceof 
checks like this.  Fixing this (bug 1360715) is not a small project, since 
there are many places in chrome code where we rely on instanceof working 
cross-context.  It is a useful check to be able to do, so at some point we'll 
likely extend Web IDL with a way to do this, but for now there is no 
standardised way to do so.

For use in the meantime, I just landed bug 1428531 on inbound, which adds a new 
chrome-only static method "isInstance" to Web IDL defined interfaces, so you 
can write for example:

  Document.isInstance(otherWindow.document)

So that we don't have even more call sites we need to fix up once we start 
looking at bug 1360715, please try to use isInstance rather than instanceof if 
you need to do cross-context DOM object tests from chrome JS.

Thanks,

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

Re: De-XBL Plans

[Cameron McCormack]

On Sat, Oct 21, 2017, at 01:47 AM, Dave Townsend wrote:
> Are there any other concerns that we're missing?

One thing I'm wondering about is memory usage of the Web Components
implementations of these components compared to the XBL ones.
Specifically for style, XBL has the ability to list the style sheets
that apply to the shadow tree declaratively, and we use that to have
only a single copy of the cascade data in memory (and we do the work of
creating the cascade data only once).  If we put 

Re: Debugging Firefox e10s with rr?

[Cameron McCormack]

On Tue, Aug 29, 2017, at 08:58 PM, Emilio Cobos Álvarez wrote:
> I didn't find any obvious docs in either the rr wiki[1] or MDN, so I
> thought I'd ask before I actually need it.
> 
> What is the best/easiest way to debug Firefox multi-process using rr?
> 
> Right now I just disable e10s, but that's probably not a great long-term
> solution...

I do that too. :-)

Mine is probably not the most efficient method, but most of the time I
record with -M, and use output lines (either turning on logging, like
RUST_LOG=debug, or adding printfs showing details of documents/elements)
to orient myself when debugging.  Doing a "rr replay -g " for a
particular output line will break in the process that printed out that
line.  (I've never had to debug something under rr that involves the
interaction between processes.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [PATCH] gfx: thebes: decouple GfxSurfaceType from cairo_surface_type_t

[Cameron McCormack]

Hi Enrico,

Firefox patches should be submitted via Bugzilla, rather than by email
to dev-platform.  Please see:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction#Step_4_-_Get_your_code_reviewed

Thanks,

Cameron

On Mon, Jul 31, 2017, at 03:14 PM, Enrico Weigelt, metux IT consult
wrote:
> ...
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: HTML scoped style sheets (

[Cameron McCormack]

On Wed, Jun 21, 2017, at 10:56 PM, Ehsan Akhgari wrote:
> Why only in the medium term?  Restyling is very costly for browser.xul 
> right now, and it would be very nice if we can use Stylo to gain some 
> advantages there, especially since costly restyles in the parent process 
> do mean UI jank for our users.  I realize that Stylo won't immediately 
> be able to style browser.xul, but it seems like we should definitely 
> prioritize getting rid of front-end side dependencies that would prevent 
> us from using it as soon as the Stylo side of things are ready and 
> sounds like the issue Jared mentioned is one such issue.  Does this 
> sound right?

By medium term, I mean "not too long after 57".  :-)  But yes, it would
be helpful to have the existing chrome document uses of 

Re: Intent to unship: HTML scoped style sheets (

[Cameron McCormack]

On Wed, Jun 21, 2017, at 02:05 AM, Bobby Holley wrote:
> Yeah - stylo for the frontend would be nice, but it's not part of
> our MVP.
Thanks for confirming what I thought was the case. :-)

On Tue, Jun 20, 2017, at 03:26 PM, Patrick Brosset wrote:
> Cameron, what bug should this one block (iiuc chrome support will be
> removed a bit later, so we have some time, do you already have a bug
> for that part?)
I'm using https://bugzilla.mozilla.org/show_bug.cgi?id=1345702 for the
removal of 

Re: Intent to unship: HTML scoped style sheets (

[Cameron McCormack]

On Tue, Jun 20, 2017, at 01:08 PM, Jared Wein wrote:
> We use a scoped stylesheet for styling the popup for  [1]. We
> chose this route to limit performance impact as well as limit our
> temporary stylesheet from affecting other parts of the browser UI.
> Will your removal also remove support in the chrome/parent process?
For now we'll keep  available in chrome documents.  But in
the medium term , we will want to style chrome documents with Servo too
https://bugzilla.mozilla.org/show_bug.cgi?id=1294570, and at that point
we'll have to remove