Intent to Unship: registerProtocolHandler() over insecure contexts

registerProtocolHandler() gives a webpage a mechanism to register itself to control a protocol after a user consents. For example, a chat application could control the irc: scheme (named protocol in the API). Chromes current telemetry suggests a usage of 0.002836% on insecure pages which is low

Intent to ship: CSS paint-order for HTML text

As of Firefox 60, I intend to turn CSS paint-order for HTML text on by default. It has been developed behind the layout.css.paint-order.enabled preference. I am not aware of any other UAs yet shipping this feature, but since our intent to implement, the CSS WG has agreed to include this in

Re: Why do we track bidiness on text nodes?

On Tue, Feb 6, 2018, at 12:09 AM, Henri Sivonen wrote: > We appear to track bidiness on the document and on the text nodes. The > document-level comment says: > /** >* Indicate the document contains bidi data. >* Currently, we cannot disable bidi, because once bidi is enabled, >* it

[desktop] Bugs logged by Desktop Release QA in the last 8 days

Hello, Here's the list of new issues found and filed by the Desktop Release QA team last week. Additional details on the team's priorities last week, as well as the plans for the current week are available at: https://goo.gl/uhgYjc Bugs logged by Desktop Release QA in the last 8 days * ASSI -

Why do we track bidiness on text nodes?

We appear to track bidiness on the document and on the text nodes. The document-level comment says: /** * Indicate the document contains bidi data. * Currently, we cannot disable bidi, because once bidi is enabled, * it affects a frame model irreversibly, and plays even though * the

Re: Why do we track bidiness on text nodes?

On Mon, Feb 5, 2018 at 4:22 PM, Xidorn Quan wrote: > I suppose you are talking about nsTextFragment::FragmentBits::mIsBidi? Yes. > Looking at callsites of nsTextFragment::IsBidi, my guess is that it is needed > so that we don't need to scan a text node when it is bound to the

Intent to implement and ship navigator.webdriver

Summary: I intend to implement and ship a new enumerable, non-configurable, read-only "webdriver" attribute on the Navigator object. The attribute is true when the -marionette flag is passed to Firefox or the marionette.enabled preference is true. Otherwise it is false. Motivation: To give web

Re: Intent to implement and ship navigator.webdriver

On 2/5/18 11:47 AM, Boris Zbarsky wrote: All the IDL snippets in this standard are empty, which makes it hard to evaluate the standard or how our implementation aligns with it. And in particular, the implementation patches don't match the intent description (e.g. we implement a configurable

Re: Intent to implement and ship navigator.webdriver

On 2/5/18 11:37 AM, Andreas Tolfsen wrote: Standard: https://w3c.github.io/webdriver/webdriver-spec.html#interface All the IDL snippets in this standard are empty, which makes it hard to evaluate the standard or how our implementation aligns with it. -Boris

Re: Intent to implement and ship navigator.webdriver

On Tue, Feb 6, 2018 at 3:37 AM, Andreas Tolfsen wrote: > Motivation: > To give web authors a way to infer if user agent is controlled by > automation, so the document can take alternate code paths when under > test. Can you speak more about why this is a good idea? I've poor