Re: On longstanding webcompat issue about padding-bottom/padding-right missing in scroll containers

Thanks for untangling this mess! Always great to see. On Thu, Mar 25, 2021 at 8:20 PM Ting-Yu Lin 林庭宇 wrote: > [1] This table > in > the spec issue summarizes the webcompat situation across different element > types and

Re: Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors

On Wed, Mar 10, 2021 at 9:11 AM Masayuki Nakano wrote: > Indeed, in long term goal must be that we'd dispatch exactly same wheel > events as Chrome/Chromium. However, without implementing alternative new > API, web apps will not be able to handle raw value for better UX. > Therefore, I filed a

Re: Intent to ship: Return pixel deltas in wheel event if deltaMode is not checked by authors

On Tue, Mar 9, 2021 at 4:45 PM Emilio Cobos Álvarez wrote: > Let me know if you have any concerns with this or what not. So if I understand it correctly we'll have a getter with side effects. Is the expectation that we can eventually remove this? Are other browsers on board with this model?

Re: Intent to prototype and ship: :user-valid and :user-invalid pseudo-classes.

On Tue, Feb 23, 2021 at 9:49 PM fantasai wrote: > We wanted it to be flexible enough that UAs could experiment with behavior and > improve usability over time, so we locked down the one period in time that we > felt was not up for debate (between attempted submission and next interaction > with

Re: Intent to prototype and ship: :user-valid and :user-invalid pseudo-classes.

On Mon, Feb 22, 2021 at 2:59 PM Emilio Cobos Álvarez wrote: > Let me know if you have any objections about this change, but I think > having a prefixed pseudo-class for this is not a great state of affairs. This seems reasonable, but I think we should define the processing model for them in the

Re: Intent to unship: FTP protocol implementation

On Wed, Feb 10, 2021 at 9:37 AM Valentin Gosu wrote: > FTP support is currently disabled on Nightly. Does this have any impact on the URL parser? Do we still (want to?) support the ftp scheme in form submission (to then delegate the computed URL to some kind of handler rather than the browser)?

Re: Intent to ship: beforeinput event and InputEvent.getTargetRanges()

On Fri, Jan 29, 2021 at 3:07 AM Masayuki Nakano wrote: > Therefore, we probably ship > `beforeinput` aligned to current Blink (this is the default behavior in > Nightly channel). And then, we should change the behavior to conform to > new Level 1, when Blink updates its behavior. Even though

Re: Intent to ship: remote-protocol (CDP)

On Tue, Jan 12, 2021 at 5:43 PM James Graham wrote: > CDP is not part of any web standard, and is not exposed to content. Seems unfortunate we cannot standardize on this format if we have to support it anyway, but I guess that was already considered and found not feasible?

Re: Intent to Ship: Make wheel event listeners passive by default on the root

On Mon, Oct 26, 2020 at 5:45 PM Emilio Cobos Álvarez wrote: > Standard: None, this is an intervention, though > https://w3c.github.io/uievents/#cancelability-of-wheel-events is loosely > related. I'm not sure "it's an intervention" is sufficient reason as making breaking changes to the web

Re: Intent to ship: Update browsing context name on cross site navigation or history traversal

On Fri, Sep 11, 2020 at 10:55 PM Shuran Huang wrote: > Thanks for the pointer. I did not realize it's about the cross-origin > navigation that not switch BrowsingInstance. Just to confirm, is the case for > top-level navigation only or not? Cross-origin navigations of top-level browsing

Re: Intent to ship: Update browsing context name on cross site navigation or history traversal

On Fri, Sep 11, 2020 at 5:00 PM Shuran Huang wrote: > FYI, here is the tracking bug for this issue in Chrome: crbug.com/1090128. Hey Shuran, I think the bug you're looking for is https://bugs.chromium.org/p/chromium/issues/detail?id=706350. In particular this intent to ship is about resetting

Intent to ship: returning shared memory to the web

At the end of August 2019 we expressed an intent to prototype the re-enablement of SharedArrayBuffer[1]. Many bugs and design iterations later, we’re happy to announce that it’s now ready. We would like to ship this in Firefox 79 or 80. To do this in a post-Spectre-safe manner we have worked with

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

On Sun, Feb 16, 2020 at 10:19 PM 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

Re: Intent to prototype and ship: lazy load images

On Mon, Feb 10, 2020 at 3:22 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. I think the answer to this question is more complicated. It's disabled if scripts are

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

On Thu, Feb 6, 2020 at 3:12 PM Boris Zbarsky wrote: > 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. This is a great goal and we

Re: Improvements to Web IDL exception message strings

On Mon, Feb 10, 2020 at 3:23 PM Boris Zbarsky wrote: > 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. Would

Re: Proposed W3C Charter: Service Workers Working Group

On Tue, Dec 3, 2019 at 3:58 PM L. David Baron wrote: > The W3C is proposing a revised charter for: > > Service Workers Working Group > https://www.w3.org/2019/11/proposed-sw-wg-charter-2019.html > https://lists.w3.org/Archives/Public/public-new-work/2019Nov/0004.html A couple of us looked

Re: Intent to Implement- Double-keyed HTTP cache

On Wed, Aug 21, 2019 at 7:40 PM Sebastian Streich wrote: > Estimated or target release: Firefox 70 The plan is to enable this on Firefox 72 Nightly to see if there's any fallout that needs addressing. It will not ride the trains. This is tracked by

Re: Intent to prototype: heading levels

Unfortunately, this was not a success (too many h1s got adjusted to be h2s) so we've removed this code and abandoned this particular plan for dealing with heading levels in HTML: https://bugzilla.mozilla.org/show_bug.cgi?id=1590366. ___ dev-platform

Re: Intent to prototype: re-enabling SharedArrayBuffer

On Thu, Aug 29, 2019 at 1:47 PM Anne van Kesteren wrote: > We might ship 1 and 2 on Nightly to see what kind of breakage that > gives. A risky part of this plan is that folks will have to test for > postMessage() rather than SAB support going forward. Enabling the prototype on Ni

PSA: changes to numerous DOM components on Bugzilla

Heya, In https://bugzilla.mozilla.org/show_bug.cgi?id=1594717 the DOM team requested quite a number of changes to their various components in Mozilla's Bugzilla. Those components are now prefixed with either "DOM:" or "Storage:". Please keep this in mind if you can't find a component in its usual

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

On Fri, Nov 1, 2019 at 8:35 PM Boris Zbarsky wrote: > 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? That covers it. The specification says "should"

Intent to prototype: heading levels

Summary: The HTML Standard has for the longest time defined a feature whereby you could exclusively use the h1 and sectioning elements, and user agents would take care of adjusting the heading level according to the nesting depth. Due to the complexity it never got adopted. There’s an alternative

Re: Web IDL now uses mixin syntax, not "implements"

On Wed, Sep 25, 2019 at 7:13 PM Christopher Mills wrote: > Updated our WebIDL page to include this new information: > > https://developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file#Mixins > > Let me know if you'd rather see something

Re: Please aim to add informative messages to your exceptions

On Sat, Sep 14, 2019 at 6:50 AM Boris Zbarsky wrote: > That means not using the following when throwing nsresults/DOMExceptions: > >ErrorResult::Throw(nsresult) >ErrorResult::operator=(nsresult) > > and instead using: > >ErrorResult::ThrowDOMException(nsresult, const nsACString&) > >

Re: Intent to prototype: re-enabling SharedArrayBuffer

On Thu, Aug 29, 2019 at 3:30 PM J. Ryan Stinnett wrote: > On Thu, 29 Aug 2019 at 12:48, Anne van Kesteren wrote: >> Note that SharedArrayBuffer itself is already enabled by default as >> ECMAScript (JavaScript) was never changed. And that standard requires >> a host to all

Intent to prototype: re-enabling SharedArrayBuffer

Summary: SharedArrayBuffer (SAB) is a feature that allows high-performance applications using shared-memory multi-threading to run on the web. Shortly after releasing SAB, Firefox (and other browsers) disabled SAB as part of our initial Spectre mitigations (see

Re: Intent to Implement- Double-keyed HTTP cache

On Thu, Aug 22, 2019 at 4:26 AM Martin Thomson wrote: > What is the tuple we're keying on? Top-level origin only. This still allows C to attack B in your scenario (or vice versa). There's a variety of other side channel attacks on " sites" too, including various members of the Window object,

Re: Intent to ship: Make elements always unvisited.

On Thu, Aug 8, 2019 at 8:39 PM Emilio Cobos Álvarez wrote: > Standard: https://drafts.csswg.org/selectors-4/#location (though note > https://github.com/w3c/csswg-drafts/issues/3817). So the real standard for this is https://html.spec.whatwg.org/#pseudo-classes as CSS tries to be host-agnostic

Re: Intent to ship: accumulating most JS scripts' data as UTF-8, then directly parsing as UTF-8 (without inflating to UTF-16)

On Sat, Jul 20, 2019 at 2:05 AM Jeff Walden wrote: > (*Only* valid UTF-8: any invalidity, including for WTF-8, is an immediate > error, no replacement-character semantics applied.) Wouldn't adding this allow you to largely bypass the text decoder if it identifies the content to be UTF-8?

Re: Resolving URLs in c++

On Fri, Jul 12, 2019 at 9:05 AM Boris Zbarsky wrote: > You could simplify this a bit by calling > nsContentUtils::ewURIWithDocumentCharset, but that doesn't solve most of > the issue. >From the name that sounds somewhat wrong to me too. At least, for new APIs I think we should always use UTF-8

Re: Intent to ship: Percentage opacity

On Wed, Jul 10, 2019 at 9:20 AM wrote: > Why fixing something that isn't broken and a well established standard for > something longer? https://github.com/w3c/csswg-drafts/issues/3342 as pointed out in OP offers plenty of justification to make this change. That's also a better forum if you want

Re: Changes to “ExposureGuidelines” (Intent to *)

On Sat, Jul 6, 2019 at 2:44 AM Ehsan Akhgari wrote: > Does the page need to include some of this description? It has this: # It's acceptable to merge the "intent to prototype" into the # "intent to ship" email as long as all the relevant # requirements are met. I suppose it could be a little

Changes to “ExposureGuidelines” (Intent to *)

Hi all, In consultation with others I have made some adjustments to https://wiki.mozilla.org/ExposureGuidelines. “Intent to implement” has been renamed to “Intent to prototype” to signify more clearly that the change does not affect the shipping product and has no direct relation to

Re: Intent to unship: typeMustMatch attribute on elements

On Fri, May 3, 2019 at 11:06 AM Frederik Braun wrote: > In bug 1548773, annevk suggested to unship the `typeMustMatch`attribute > from elements[1]. I've now also changed the HTML standard in https://github.com/whatwg/html/pull/4590 and updated WPT in

Re: PSA: web-platform-tests (dashboard | fuzzy-reftests | reftest comparisons)

On Mon, Apr 15, 2019 at 7:16 PM Jonathan Watt wrote: > These are all really great. Thanks, James! Indeed, thanks a lot for working on this! This will help a lot with prioritizing work and also with standards development. Some feedback for the Interop Dashboard: * It would help me a bit if it

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

On Tue, Apr 9, 2019 at 5:56 AM Cameron McCormack wrote: > 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: Intent to unship: Some Shadow DOM v0 APIs

Thanks for cleaning this up Emilio! On Sat, Mar 16, 2019 at 1:37 AM Emilio Cobos Álvarez wrote: > The code implementing them remains untouched, since it's the same for > ShadowRoot and Document, so resurrecting them should we need that would > be trivial. That seems highly unlikely. Unless live

Re: Intent to ship: implicit rel=noopener for target=_blank on anchor and area elements

On Fri, Jan 25, 2019 at 1:52 AM Tantek Çelik wrote: > I am seeing some publisher uptake of rel="noopener" so it is good that > we are shipping this. To be clear, we've supported rel="noopener" for a while. This makes it so that you don't need to specify rel="noopener" if your target attribute is

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

On Thu, Nov 22, 2018 at 6:00 PM Ehsan Akhgari wrote: > Do you mean adding a rel attribute to ? Not sure if all of the other > link type values for rel make sense for but having some way of > passing "noopener" (and "opener" for that matter) directives for is > indeed something that we should

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

On Thu, Nov 22, 2018 at 7:07 AM Ehsan Akhgari wrote: > I wonder if it makes sense to make a similar change here, to make target="_blank"> imply noopener behaviour and then if that proves to be Web > compatible, propose to change the spec to pass false there? Yeah, I think we should try to keep

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

On Wed, Nov 21, 2018 at 4:08 PM Alex Gaynor wrote: > Do we have any sense of how large the breakage will be, and do we have any > docs for developers who are impacted? (I assume rel=opener is the fix?) The "fix" would be to use target=someuniquename. And I don't think there's data, other than

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

On Tue, Nov 20, 2018 at 3:48 PM Honza Bambas wrote: > Our implementation reflects the reality we can see in the wild. I > believe the spec has always been wrong here, and apparently has never > been widely respected by servers because commas may be contained in the > challenge header values.

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

On Tue, Nov 20, 2018 at 3:15 PM Boris Zbarsky wrote: > 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

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

On Tue, Nov 20, 2018 at 9:50 AM john.bieling--- via dev-platform wrote: > Thanks for your feedback. As you have the much deeper knowledge about these > thinks, I think it would be better if you file that bug? I forgot that it was already filed and marked as a dependency:

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

On Tue, Nov 20, 2018 at 9:20 AM john.bieling--- via dev-platform wrote: > Now it looks like that nsIHttpChannel itself is not able to split > WWW-Authenticate headers? Right, I reported that in https://bugzilla.mozilla.org/show_bug.cgi?id=1491010#c22. > Should I add a link to this thread to

Re: Intent to implement and ship: WebP image support

On Thu, Oct 11, 2018 at 5:43 PM Andrew Osmond wrote: > Is this feature restricted to secure contexts?: No, it isn't. This is not a > new API, instead it is just accepting more types of content via existing > channels. This isn't the rationale you're looking for. New formats would generally be

Re: What is the future of XMLHttpRequest.mozAnon ?

On Fri, Sep 14, 2018 at 12:50 PM Gijs Kruitbosch wrote: > This seems like an issue with the fetch spec ( > https://fetch.spec.whatwg.org/#concept-header-value-combined ) that you > could report to them ( https://github.com/whatwg/fetch ) if that hasn't > already been done. FWIW, I'm pretty sure

Re: What is the future of XMLHttpRequest.mozAnon ?

On Thu, Sep 13, 2018 at 11:05 PM john.bieling--- via dev-platform wrote: > Is mozAnon going to stay or are you thinking about removing that in the > future? > > https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/mozAnon It'll be marked ChromeOnly:

Re: Intent to Implement: Storage Access API

On Tue, Sep 11, 2018 at 9:06 PM Ehsan Akhgari wrote: > Please note that Firefox will grant storage access permissions > automatically under certain circumstances for web compatibility reasons, so > even when the iframe has never called this API it may still obtain storage > access. In order to

Re: nsIClearDataService

Thanks for working on this! Clear-Site-Data seems pretty essential to have now we ship service workers. On Fri, Jun 1, 2018 at 6:26 PM, Andrea Marchesini wrote: > Note for the DOM/QuotaManager/ServiceWorker people: this component covers > all the DOM storages under 1 single flag:

Re: Proposed W3C Charter: Devices and Sensors Working Group

On Fri, May 4, 2018 at 2:07 AM, L. David Baron wrote: > On the flip side, sensor APIs are offered by mobile (and to some > degree desktop) operating systems and widely used by apps running on > them, and there's clear demand for having them on the Web. So I > think it seems

Re: Proposed W3C Charter: Devices and Sensors Working Group

On Thu, May 3, 2018 at 12:51 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. Perhaps I've missed something, but I feel like we never

Re: Proposed W3C Charter: Timed Text Working Group

On Thu, May 3, 2018 at 12:42 AM, L. David Baron wrote: > Timed Text Working Group > https://www.w3.org/2018/04/proposed-tt-charter-2018.html What does # The Group is expected to produce annual updates for the Recommendation # with previously unspecified features. mean?

Re: License of test data?

On Tue, Apr 24, 2018 at 4:24 PM, David Teller wrote: > Ideally, I'd like to put a few well-known frameworks in jsapi tests, to > be used as data for SpiderMonkey integration tests. > > What's our policy for this? Are there any restrictions? All the > frameworks I currently

Re: Intent to unship: URL.createObjectURL(MediaStream)

On Mon, Apr 23, 2018 at 9:50 AM, Andrea Marchesini wrote: > . I haven't checked edge (I don't run windows locally) Ask for a BrowserStack account (not entirely sure who arranges these though, I got mine via jst). Edge still supports it:

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

On Tue, Apr 10, 2018 at 3:58 AM, Jeff Gilbert wrote: > Do we have a heuristic for when to /not/ include something from HTML in SVG? > > More or less, these additions to SVG just strike me as having solid > potential risk (for both spec-interaction and implementation bugs)

Re: Intent to implement and ship: same-site cookies

On Tue, Apr 10, 2018 at 4:25 AM, Francois Marier wrote: > Secure contexts: not restricted to secure contexts since cookies are > already available in non-secure contexts I'm not entirely convinced that is a good enough reason. We keep trying to find ways to limit cookies

Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue

On Fri, Mar 23, 2018 at 9:16 PM, L. David Baron wrote: > I should clarify that it isn't actually non-standard: it was part > of DOM Level 2: > https://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSStyleDeclaration > but ended up never being widely implemented. It's not a >

Re: Use cases for invalid-Unicode atoms

On Wed, Mar 21, 2018 at 10:27 AM, Henri Sivonen wrote: > * A bunch of things atomicize URL components. I'd hope that the URLs > were converted from UTF-16 to UTF-8 at some prior point ensuring UTF-8 > validity, but it's hard to be sure. At least per the specification all

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Mon, Mar 19, 2018 at 11:48 AM, Martin Thomson wrote: > Yes, it pays to remember that this is Nightly. Even on Nightly we place pretty severe restrictions on ourselves when it comes to user data, e.g., for telemetry. This definitely goes beyond the kind of data I would expect

Re: FYI: Short Nightly Shield Study involving DNS over HTTPs (DoH)

On Mon, Mar 19, 2018 at 8:10 AM, Henri Sivonen wrote: > On Mon, Mar 19, 2018 at 3:18 AM, Eric Shepherd (Sheppy) > wrote: >> I definitely see some easy ways this could be problematic from a public >> relations perspective given things going on in the

Re: Proposed W3C Charter: Web Payments Working Group

On Fri, Feb 2, 2018 at 7:49 PM, Peter Saint-Andre wrote: > What you have seems fine (modulo s/Web Auth/Web Authentcation/). The > first comment is just housekeeping, whereas the second comment is > substantive and concerning. Phrasing it as a formal objection might > result

Re: Requiring secure contexts for new features

On Wed, Jan 17, 2018 at 12:02 AM, Martin Thomson wrote: > Either of these criteria are sufficient, right? However, I expect > that we'll want to hold the line in some cases where other browsers > ship anyway. How do we plan to resolve that? One potential > resolution to that

Requiring secure contexts for new features

Yesterday Mozilla announced Firefox will be restricting new features to secure contexts (i.e., HTTPS): https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/ I'm glad to report that thus far this has been very well received. I'm posting this here per suggestion from Ben

Re: Device Orientation API future

On Thu, Jan 11, 2018 at 6:48 PM, Blair MacIntyre wrote: >> In that case I'm not entirely sure why we'd also pursue new >> variants separately. > > I’m not sure what this means? That if our main usage for the new sensor APIs (those discussed in

Re: Device Orientation API future

On Thu, Jan 11, 2018 at 5:30 PM, Blair MacIntyre wrote: > First, this discussion pertains to FF on Windows, Mac, Android and Linux, I > assume? FF for iOS just uses the wkWebView and it’s up to Apple to decide on > things like this. Is this correct? I believe there's

Re: Device Orientation API future

On Thu, Jan 11, 2018 at 5:39 AM, Chris Van Wiemeersch wrote: > Anne and Martin, can you think of changes to request for the Sensor API > that we would resolve or reasonably improve the existing fingerprinting > concerns? It sounds like Chrome's approach is throttling, which

Re: Device Orientation API future

On Wed, Jan 10, 2018 at 4:23 AM, wrote: > 1. Lock down the Device Sensor APIs APIs in Gecko to only secure contexts, > with `deviceorientation`, `absolutedeviceorientation`, and `devicemotion` > being enabled by default. This helps with encouraging HTTPS adoption, but

Re: Intent to unship: navigator.registerContentHandler()

On Wed, Jan 10, 2018 at 2:06 AM, Fabrice Desre wrote: > WebShare is more a trimmed down version of the WebActivities/WebIntents > apis. I think it's unfortunate that instead of fixing the issues with WA/WI > they went with a single purpose API - this doesn't scale at all with

Re: Intent to unship: navigator.registerContentHandler()

On Tue, Jan 9, 2018 at 5:30 PM, Gervase Markham wrote: > I'm sure unshipping it is the right thing to do, but it's very sad. :-( > Allowing web pages to register for content types and protocols seems > kind of important if you want the web to have the capability of > seamlessly

Re: Device Orientation API future

On Thu, Jan 4, 2018 at 11:15 AM, Blair MacIntyre wrote: > If we are going to break existing websites, then perhaps looking at the > Generic Sensor API (as CVan suggests in his email) is a more rational > approach; is it implemented in FF yet? Plans for it? See

Re: Intent to remove Ambient Light and Proximity sensor APIs

On Mon, Dec 18, 2017 at 7:36 PM, Gervase Markham wrote: > appear.in, which supports both audio and video calling via WebRTC, works > in Firefox for Android, although performance is not awesome on my Z3C > Compact. > > It does not blank the screen when you place the device to

Re: W3C Proposed Recommendations: WAI-ARIA and Core Accessibility API Mappings

On Fri, Dec 1, 2017 at 11:49 AM, Jonathan Kingston wrote: > If roles are mapped 1:1 to HTML features we basically: > - Promote the use of bad markup and the expectation that bad markup will > use good ARIA. It's pretty clear that and et al have limitations that are not

Re: Browser Architecture Newsletter 5

On Wed, Nov 29, 2017 at 9:47 PM, Dave Townsend wrote: > If you’re working on improving storage or syncing of data in any of our > products or projects, on any platform, or if you’re currently struggling to > work with what currently exists, then we’d like to hear from you

Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code

On Thu, Nov 30, 2017 at 12:00 AM, Kris Maglione wrote: > I don't think this is true. The native filename isn't even available to JS, > which always deals with UTF-16 strings. JS deals with 16-bit unsigned integers. In particular, you can represent lone surrogates in JS,

Re: Any intent to implement the W3C generic sensor API in Firefox?

On Thu, Nov 9, 2017 at 6:29 AM, Boris Zbarsky wrote: > On 11/3/17 3:00 PM, Jonathan Kingston wrote: >> Which specific issues? >> The API in the specification is promise ready by using the permissions >> API, >> is behind a permission prompt and requires a secure context. > >

Re: Intent to ship: (hyperlink auditing)

On Tue, Oct 17, 2017 at 11:00 PM, James Graham wrote: > Are there cross-browser (i.e. wpt) tests for this feature? Not that I know of, html/semantics/links/downloading-resources/ is still empty. I added a comment to our bug. -- https://annevankesteren.nl/

Re: Threadsafe URLs - MozURL

On Mon, Oct 23, 2017 at 4:01 PM, Valentin Gosu wrote: > A few weeks ago we landed MozURL. This is an immutable threadsafe wrapper > for rust-url. What is the plan for these issues: https://github.com/servo/rust-url/issues/163

Intent to ship: (hyperlink auditing)

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=951104 Rationale: There's already a myriad of ways to obtain this data through script. We might as well ship the protocol that both Chrome and Safari ship in the hope that along with sendBeacon() it decreases the usage of the slower alternatives;

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Mon, Oct 2, 2017 at 6:09 PM, Boris Zbarsky wrote: > On 10/2/17 12:03 PM, Daniel Veditz wrote: >> Fair enough. Could we propose improvements to the APIs that would make >> them more usable? For example an object argument to createElement() that >> contained attribute/value

Re: Status of deprecating non-secure HTTP

On Mon, Sep 25, 2017 at 2:47 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: > On 9/25/17 3:18 AM, Anne van Kesteren wrote: >> But it would also be good if we could all communicate this on behalf >> of Mozilla without caveats. E.g., Chrome might ship worklets soon and &g

Status of deprecating non-secure HTTP

It seems that with Richard leaving Mozilla we dropped the ball on requiring HTTPS more often: https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/ At least I can't find any follow-up with an agreed upon date and we're still rather hit-or-miss when it comes to using

Re: Device orientation/motion events privacy issues

On Fri, Sep 22, 2017 at 4:50 PM, Ehsan Akhgari wrote: > We discussed this a bit with Anne on IRC. It seems like this API is a good > use case for a permission prompt to the user. Since the API works by > registering an event listener, the only realistic option seems to

Re: Intent to ship: CSP directive worker-src

On Fri, Sep 22, 2017 at 4:18 PM, Christoph Kerschbaumer wrote: > We plan to ship the CSP directive worker-src within Firefox 58. Will we also start enforcing script-src for workers? It seems good that if you restrict script it actually stops all scripts. --

Re: Eiminating nsIDOM* interfaces and brand checks

On Fri, Sep 1, 2017 at 5:01 PM, Boris Zbarsky wrote: > Thoughts? It really would be nice to get rid of some of this stuff going > forward. And since the web platform seems to be punting on branding, > there's no existing solution we can use. It's punting on exposing it to web

Re: nsIURI API changes - punycode domain names

On Wed, Aug 9, 2017 at 8:37 PM, Boris Zbarsky wrote: > On 8/9/17 1:43 PM, Daniel Veditz wrote: >> >> What do web pages do if they want to reflect a pretty URL into their page? > > Cry, basically. I have a proposal: https://github.com/whatwg/url/pull/288. There's two issues:

Restricting the Notifications API to secure contexts

Chrome wants to restrict the Notifications API https://notifications.spec.whatwg.org/ to secure contexts: https://github.com/whatwg/notifications/issues/93 https://github.com/w3c/web-platform-tests/pull/6596 Given that the API involves prompting the user as well as a permission that remains

Re: Intent to remove: sensor APIs

On Wed, Aug 2, 2017 at 4:39 PM, Blair MacIntyre wrote: > Are we still talking about deviceorientation? As I said twice and Frederik repeated, we're not, other than asking if anyone has a plan for how to make it interoperable. Note that it's far from a W3C standard:

Re: Intent to remove: sensor APIs

On Mon, Jul 24, 2017 at 6:11 PM, Anne van Kesteren <ann...@annevk.nl> wrote: > Please consider the request to remove device orientation retracted for > now. We'll still need to figure out some kind of long term plan for > that API though. WebVR building on it through libraries that

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

Hey Enrico, patches are certainly appreciated, but please attach them (and corresponding rationale) to bugs instead. This one should probably go here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Core=Graphics. dev-platform has a ton of subscribers and is really only meant for more

Re: Intent to remove: sensor APIs

Please consider the request to remove device orientation retracted for now. We'll still need to figure out some kind of long term plan for that API though. WebVR building on it through libraries that abstract away the browser incompatibilities will just make it harder to fix the underpinnings

Intent to remove: sensor APIs

As a follow-up to the Ambient Light Sensor API thread, which ended up not really concluding, I hereby suggest we remove the various sensor APIs from our code base. Flipping the preference first to make sure there's no undue impact on web content and quick reversal is possible and then removing the

Re: W3C Charter Advance Notice: Web Platform (recharter) & Service Workers WGs

On Tue, Jul 11, 2017 at 8:38 PM, L. David Baron wrote: > Also, for what it's worth, given offline feedback, I plan to support > the Service Workers WG charter. Apparently much of the discussion > about service workers happens in WHATWG forums, but it still seems > valuable to

Re: Proposed W3C Charter: WebAssembly Working Group

On Tue, Jul 11, 2017 at 3:29 AM, L. David Baron wrote: > The standard sentence: > "Most WebAssembly Working Group teleconferences will focus on > discussion of particular specifications, and will be conducted on an > as-needed basis." > doesn't seem to make sense for a

Re: Intent to unship: moz*Frames attributes of HTMLVideoElement

On Fri, Jul 7, 2017 at 5:57 PM, Ehsan Akhgari wrote: > Yes indeed. (I just commented the same about unshipping another feature in > a different thread, so I won't repeat literally all of the same points here, > but they all apply here too!) I created

Re: Leakage of amount of storage used

On Mon, Jul 10, 2017 at 8:54 AM, Shawn Huang wrote: > I wondered that it's easy to find the identity by collecting how much space > all other origins take up together. It's possible that the size of other > origins that user has visited could change next time. Unless users

Re: Intent to unship: moz*Frames attributes of HTMLVideoElement

On Fri, Jul 7, 2017 at 8:51 AM, Jet Villegas wrote: > Depending on what you find, we may have to keep this API around :-/ Yeah, I would expect us to follow the "normal" deprecation and remove path to be more confident in the eventual unshipping: 1. Gather telemetry on how

Re: Leakage of amount of storage used

On Fri, Jun 30, 2017 at 10:47 AM, Tom Tung wrote: > I think there are the similar issue but not the same. The bug 1290481 is > focus on not exposing the size of opaque responses while the leakage of > amount of storage used is about exposing overall usage of other origins.

Leakage of amount of storage used

Persistent storage gets the global quota. We also expose the local quota (that of the origin). That means that by filling up space you can determine how much space all other origins take up together. Persistent storage for an origin is user opt-in through a dialog (and maybe "add to

  1   2   3   4   >