Op zondag 29 maart 2020 08:24:06 UTC+2 schreef Emilio Cobos Álvarez:
> Hey, a quick web-observable change that may deserve a bit more
> visibility / an intent.
>
> I'd welcome some feedback, specially from the fingerprinting / privacy
> angle (where I'm clearly not an expert).
>
> Summary: A pa
On 3/30/20 8:02 PM, Bobby Holley wrote:
Reading the post a few times, I'm still unclear on a few things, so would
appreciate clarification. Here's what I understand from the post:
On the user's machine, there is some entropy, i.e. the set of schemes for
which an external protocol handler is regi
Reading the post a few times, I'm still unclear on a few things, so would
appreciate clarification. Here's what I understand from the post:
On the user's machine, there is some entropy, i.e. the set of schemes for
which an external protocol handler is registered. This entropy is currently
retrieva
On 3/29/20 9:11 AM, Emilio Cobos Álvarez wrote:
Doing a bit of digging,
https://bugzilla.mozilla.org/show_bug.cgi?id=680300 contains some more
interesting context...
We apparently used to sync-throw when assigning location.href to an
unknown protocol URI in the past, there we changed it to si
Doing a bit of digging,
https://bugzilla.mozilla.org/show_bug.cgi?id=680300 contains some more
interesting context...
We apparently used to sync-throw when assigning location.href to an
unknown protocol URI in the past, there we changed it to silently fail,
and now it is navigating to an erro
This landed in https://hg.mozilla.org/mozilla-central/rev/724d7b936078
To replicate the prior output, use MOZ_LOG="DocShellAndDOMWindowLeak:3"
Because it now includes the MOZ_LOG prefix, any custom scripts you had to
parse the output will need to be updated.
-tom
On Fri, Nov 8, 2019 at 2:44 PM
On Tuesday, August 28, 2018 at 5:16:14 PM UTC-7, kgil...@mozilla.com wrote:
> Hi David,
>
> These are all great points, thanks for reviewing this.
>
> The intent is to not allow WebXR in any iframe (not just sandboxed ones),
> until the discussions have settled. I appreciate the feedback on the
This sounds great. Is there a reason we can't just use MOZ_LOG for the
docshell/domwindow logging?
-e
On Fri, Nov 8, 2019 at 2:44 PM Tom Ritter wrote:
> In https://bugzilla.mozilla.org/show_bug.cgi?id=1592297 I plan/hope to
> remove MOZ_QUIET and turn off the DOCSHELL/DOMWINDOW logging by defa
Thank you for doing this.
On Fri, Nov 8, 2019 at 2:44 PM Tom Ritter wrote:
> In https://bugzilla.mozilla.org/show_bug.cgi?id=1592297 I plan/hope to
> remove MOZ_QUIET and turn off the DOCSHELL/DOMWINDOW logging by default.
> It will automatically be enabled in browser-chrome tests where it is
>
Thanks, that's a good point indeed. I prefer adding a console warning in
this case.
On Tue, Jul 2, 2019 at 9:23 PM Panos Astithas wrote:
> On Tue, Jul 2, 2019 at 6:16 AM Thomas Nguyen wrote:
>
>> DevTools bug: No
>>
>
> Wouldn't it be helpful to indicate such truncation in the console (as a
>
On Tue, Jul 2, 2019 at 6:16 AM Thomas Nguyen wrote:
> DevTools bug: No
>
Wouldn't it be helpful to indicate such truncation in the console (as a
warning) or network panel (with a request badge)? I can imagine developers
being confused about why the referrer header is not what they expect it to
On Fri, Jun 14, 2019 at 3:25 AM violet wrote:
> Preference behind which this will be implemented:
> layout.css.overflow-logical.enabled
>
> Enabled by default.
>
Enabled by default sounds fine to me in this case.
Thanks for doing this,
Sean
___
dev-pl
On 3/27/19 5:19 AM, L. David Baron wrote:
On Wednesday 2019-03-27 01:42 +0100, Mats Palmgren wrote:
FYI, the CSS Lists spec isn't very well maintained, sadly,
so it's not up-to-date with recent resolutions. So, some
of the finer details in there might be wrong, but I think
most of it regarding
On 6/17/19 11:02 AM, saschan...@gmail.com wrote:
Summary: Expose DOMMatrix/DOMPoint/DOMQuad/DOMRect to workers and enable
structured cloning for them.
Note that this also allows storing these objects in IndexedDB, via
implementing the equivalent of
https://html.spec.whatwg.org/multipage/stru
On 6/14/19 6:23 AM, violet wrote:
Preference behind which this will be implemented:
layout.css.overflow-logical.enabled
Thank you.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Preference behind which this will be implemented:
layout.css.overflow-logical.enabled
Enabled by default.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
> It's probably a good idea to have a pref controlling whether these get
parsed, so we can disable if needed if there's an issue, given that no
one has shipped these yet in a final release.
Ok, I'll add a flag for this.
> Are these just logical versions of the existing overflow-x and
overflow-y p
> Chrome has shipped these properties in latest Canary, commit:
> https://chromium.googlesource.com/chromium/src/+/985a82ce4c869aca8e33dc213293a37b2764d69c
To clarify, Chrome has just implemented a few days ago, it's not "shipped" yet.
The status can be found here:
https://chromium.googlesource.
On 6/13/19 4:15 AM, violet wrote:
Preference behind which this will be implemented: none.
It's probably a good idea to have a pref controlling whether these get
parsed, so we can disable if needed if there's an issue, given that no
one has shipped these yet in a final release. Or are there t
On 6/7/19 8:47 AM, Andrea Marchesini wrote:
Summary: implement and ship 3 new methods to read Blob contents:
blob.text(), blob.arrayBuffer() and blob.stream().
Looks good to me.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
http
Just as a PSA, I did a bunch of work a while ago to align better with
other UAs, and the Gecko-specific values are gone as a result of that work.
The CSSWG resolved in our behavior regarding `auto` in:
https://github.com/w3c/csswg-drafts/issues/3344
So I plan to land the changes in 69 now th
On Friday, August 21, 2015 at 11:04:00 PM UTC-4, Birunthan Mohanathas wrote:
> Hi,
>
> navigator.permissions.query has been Nightly-only for a few weeks. We
> are going to let it ride the trains. Other parts of the spec (such as
> Permissions.request) will be implemented when the spec is complete.
On Monday, April 15, 2019 at 9:21:57 AM UTC+2, Makoto Kato wrote:
> Hi, Mirko. (I mistake email address. sorry)
>
> Does this work on GeckoView/Android too? When showing software keyboard,
> web page may be scrolled without focus manager.
For the record: GeckoView will need to be adapted separa
Hi, Mirko. (I mistake email address. sorry)
Does this work on GeckoView/Android too? When showing software keyboard,
web page may be scrolled without focus manager.
-- Makoto
On Thu, Apr 11, 2019 at 11:35 PM Mirko Brodesser
wrote:
> *Summary*: this allows web-developers to focus an element w
The multiplage version of the spec (for folks with slower machines):
https://html.spec.whatwg.org/multipage/interaction.html#dom-focusoptions-preventscroll
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/d
Are there also plans to revisit our longstanding
foreground/background/link/visited-link colouring prefs (as well as
their companion use_system_colors pref) in light of this set of changes?
They've never really worked very well, nobody has really taken on fixing
their UX, and it would be nice i
On Wed, Mar 20, 2019 at 8:45 AM Hiroyuki Ikezoe wrote:
> The Android backend for prefers-color-scheme didn't get on Firefox 67,
> it's just landed on mozilla-central, will be shipped in Firefox 68.
>
The backend was uplifted into Firefox 67 beta yesterday. So
prefers-color-scheme will be availa
On Wednesday 2019-03-27 01:42 +0100, Mats Palmgren wrote:
> FYI, the CSS Lists spec isn't very well maintained, sadly,
> so it's not up-to-date with recent resolutions. So, some
> of the finer details in there might be wrong, but I think
> most of it regarding counters is correct.
If you've been
On 3/27/19 12:30 AM, Domenic Denicola wrote:
(On-list this time)
However, the actual semantics for how list items work are exclusively
defined by CSS ([css-lists], [css-pseudo]). The above mentioned HTML
elements/attributes simply maps to the relevant CSS properties, using
a built-in 'list-item
(On-list this time)
> However, the actual semantics for how list items work are exclusively defined
> by CSS ([css-lists], [css-pseudo]).
> The above mentioned HTML elements/attributes simply maps to the relevant CSS
> properties, using a built-in 'list-item' counter.
Where does [css-lists] an
On 3/25/19 6:21 AM, Domenic Denicola wrote:
> The spec at https://drafts.csswg.org/css-lists/#declaring-a-list-item
> seems to contradict that hard-fought consensus. It seems like a
> regression to implement list item numbering according to that spec,
> instead of according to HTML.
As others hav
Note that the spec does not yet reflect the decisions made at the last F2F, or
the subsequent decisions from Issues.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Tuesday 2019-03-26 14:25 -0700, Domenic Denicola wrote:
> It's great to hear that this isn't a regression in the way I expected. I
> think I was thrown off by the phrasing of the OP, which implied to me a
> switch from following the HTML spec to following the CSS lists spec. As I
> noted, the
It's great to hear that this isn't a regression in the way I expected. I think
I was thrown off by the phrasing of the OP, which implied to me a switch from
following the HTML spec to following the CSS lists spec. As I noted, the CSS
lists spec contradicts the HTML spec, e.g. disallowing reverse
On Sunday 2019-03-24 22:21 -0700, Domenic Denicola wrote:
> Some time ago we spent some effort documenting a cross-browser
> mostly-interoperable behavior for list-item-like behaviors, in
> https://github.com/whatwg/html/pull/2002 and linked threads. The result is
> the spec at
> https://html.s
On Mon, Mar 25, 2019 at 10:05 PM wrote:
> > As far as separating the value; it kind of depends on how you
> > implement it; but let's say you were going to use a static uint64_t or
> > something like that. Instead of heaving a static uint64_t, create a
> > Dictionary and look up the uint64_t usin
On 25/03/2019 06:21, Domenic Denicola wrote:
> Some time ago we spent some effort documenting a cross-browser
> mostly-interoperable behavior for list-item-like behaviors, in
> https://github.com/whatwg/html/pull/2002 and linked threads. The result is
> the spec at
> https://html.spec.whatwg.or
On Friday, March 22, 2019 at 9:56:20 AM UTC-7, Martin Thomson wrote:
> On Thu, Mar 21, 2019 at 1:11 PM Tom Ritter wrote:
>
> > Okay, good, not making this data available until the user activity
> > engages with the gamepad/VR controller (mostly) assuages my concerns
> > on this component. My rema
On Wednesday, March 20, 2019 at 7:10:54 PM UTC-7, Tom Ritter wrote:
> > > > Example 1: Let’s say touchId is currently set to 0 and no fingers are
> > > > touching the touchpad. When a finger touches the touchpad, touchId of
> > > > this event would be 1. As that finger moves around the touchpad
On Sunday, March 24, 2019 at 10:21:10 PM UTC-7, Domenic Denicola wrote:
> the tests at
> https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-ol-element
correction,
https://github.com/web-platform-tests/wpt/tree/master/html/semantics/grouping-content/the-li
Some time ago we spent some effort documenting a cross-browser
mostly-interoperable behavior for list-item-like behaviors, in
https://github.com/whatwg/html/pull/2002 and linked threads. The result is the
spec at https://html.spec.whatwg.org/multipage/grouping-content.html#list-owner
and the te
On Thu, Mar 21, 2019 at 1:11 PM Tom Ritter wrote:
> Okay, good, not making this data available until the user activity
> engages with the gamepad/VR controller (mostly) assuages my concerns
> on this component. My remaining concern is around the sensitivity of
> axis movement. If I have my contro
> > > Example 1: Let’s say touchId is currently set to 0 and no fingers are
> > > touching the touchpad. When a finger touches the touchpad, touchId of
> > > this event would be 1. As that finger moves around the touchpad, new
> > > touch events are added with updated coordinates, however, the
On Friday, March 15, 2019 at 8:35:41 AM UTC-7, Tom Ritter wrote:
> Thanks for more details on the use case.
>
> On Wed, Mar 6, 2019 at 1:35 AM wrote:
> >
> > On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote:
> > > To add to Dan's comments here...
> > >
> > > Assuming that I'
It's https://bugzilla.mozilla.org/show_bug.cgi?id=1532850, it was at a
deeper level of blockers of bug 1494034, now I added bug 1532850 in the
dependency list of bug 1494034.
Thanks,
hiro
On Wed, Mar 20, 2019 at 9:42 AM Eric Shepherd (Sheppy) <
esheph...@mozilla.com> wrote:
> Presumably that’s n
Presumably that’s noted appropriately in some manner in Bugzilla?
On March 19, 2019 at 7:45:53 PM, Hiroyuki Ikezoe (hike...@mozilla.com)
wrote:
The Android backend for prefers-color-scheme didn't get on Firefox 67, it's
just landed on mozilla-central, will be shipped in Firefox 68.
Eric Shepher
The Android backend for prefers-color-scheme didn't get on Firefox 67, it's
just landed on mozilla-central, will be shipped in Firefox 68.
Thanks,
hiro
On Sat, Feb 16, 2019 at 5:38 AM Mats Palmgren wrote:
> Summary:
> The 'prefers-color-scheme' media feature is way for pages to detect
> if the
On Fri, Mar 15, 2019 at 11:35 AM Tom Ritter wrote:
> Thanks for more details on the use case.
>
> On Wed, Mar 6, 2019 at 1:35 AM wrote:
> >
> > On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote:
> > > To add to Dan's comments here...
> > >
> > > Assuming that I'm reading thi
Thanks for more details on the use case.
On Wed, Mar 6, 2019 at 1:35 AM wrote:
>
> On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote:
> > To add to Dan's comments here...
> >
> > Assuming that I'm reading this correctly [1], the fingerprinting risks are
> > pretty extreme her
Hello, fantasai!
On Sun, Mar 10, 2019 at 6:14 AM fantasai
wrote:
> 1. Handling overlarge snap areas per
> https://www.w3.org/TR/css-scroll-snap-1/#snap-overflow
> This is important to make content accessible on smaller-than-expected
> screens.
>
I think I've finished this properly, but..
2
All of this sounds great to me, and I'm pretty excited that Mozilla will
be updating to the latest spec. Most of the changes were in response to
roc's feedback on the spec, and make it a much more robust system for the
variable environment of the Web.
There's a couple things I want to make sure y
On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote:
> To add to Dan's comments here...
>
> Assuming that I'm reading this correctly [1], the fingerprinting risks are
> pretty extreme here. In the touch spec, we have a monotonically increasing
> counter that doesn't appear to b
On Wed, Feb 27, 2019, at 6:43 AM, James Graham wrote:
> The current thinking is that hardware interaction APIs which rely on
> mocks to test should specify the API for testing as part of the
> specification (e.g. [1]). So it seems like the same approach could be
> used here.
>
> [1] https://web
On 26/02/2019 22:49, d...@mozilla.com wrote:
On Tuesday, February 26, 2019 at 2:15:57 AM UTC-8, James Graham wrote:
On 25/02/2019 19:44, Daosheng Mu wrote:
web-platform-tests: none exist (and I don't plan to write WPTs but we do
have gamepad mochitest, I will add new tests to cover these tw
On Tuesday, February 26, 2019 at 2:15:57 AM UTC-8, James Graham wrote:
> On 25/02/2019 19:44, Daosheng Mu wrote:
>
> > web-platform-tests: none exist (and I don't plan to write WPTs but we do
> > have gamepad mochitest, I will add new tests to cover these two new APIs.)
>
> Why do you plan to not
--
Daosheng Mu
Software Engineer | Mozilla
d...@mozilla.com
On Tue, Feb 26, 2019 at 1:14 AM Julien Cristau wrote:
> On Mon, Feb 25, 2019 at 8:45 PM Daosheng Mu wrote:
>
>> Is this feature restricted to secure contexts? Nope
>>
>
> Why not?
>
> I agree. I will make it be restricted to secure co
On 25/02/2019 19:44, Daosheng Mu wrote:
web-platform-tests: none exist (and I don't plan to write WPTs but we do
have gamepad mochitest, I will add new tests to cover these two new APIs.)
Why do you plan to not write web-platform-tests? I imagine there may be
technical challenges, but we s
On Mon, Feb 25, 2019 at 8:45 PM Daosheng Mu wrote:
> Is this feature restricted to secure contexts? Nope
>
Why not?
Cheers,
Julien
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
To add to Dan's comments here...
Assuming that I'm reading this correctly [1], the fingerprinting risks are
pretty extreme here. In the touch spec, we have a monotonically increasing
counter that doesn't appear to be origin-bound in any way. What is the
purpose of this identifier? In the light
Hi Daniel,
We didn't have a chance to discuss privacy issues in Gamepad Extension or
Gamepad API. We were trying to get responses for the Privacy review [1] but
without any updates yet.
Cheers,
[1] https://lists.w3.org/Archives/Public/public-privacy/2018AprJun/0030.html
--
Daosheng Mu
Software
Neither of the words "security" or "privacy" appear in this spec (most w3
web specs have at least a token attempt at a "Privacy and Security
Considerations" section). At a surface glance this appears to add
additional fingerprinting exposure. Have you talked to the privacy team
about ways to minimi
On Fri, Jan 18, 2019, at 7:46 AM, Mats Palmgren wrote:
> Summary:
> The border-{start,end}-{start,end}-radius CSS properties are flow-relative
> versions of their corresponding physical property, border-top-left-radius etc
>
> Bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1520684
>
> Link t
> Do other browser engines implement this?
> I don't know, there was no WPT for these.
I didn't implement them in Blink because they were added into the spec after I
sent the intent to implement. So I should send a new one for them.
Also, the mapping is not clear in the spec
(https://github.com
On 1/14/19 9:09 PM, fantasai wrote:
I have no idea why I did that. Fixed.
Thank you!
Yes, the spec reflects general consensus, and has been explicitly cleared
for shipping by the CSSWG (as of several years). See issue at the bottom
of the intro:
https://www.w3.org/TR/css-logical-1/#intro
On 12/11/18 6:34 AM, Boris Zbarsky wrote:
>
> Spec stability: Not 100% clear, but I expect it's pretty stable; on the spec level this is a tiny
change and there's not much controversy about which letter to use for the flag, I would think.
As the editor of the spec, I second this assessment. The
On 12/23/18 2:59 AM, Emilio Cobos Álvarez wrote:
Summary: More explicitly expose the kind of handling for overflowing content in media queries. Using
a media expression instead of the print media type allows for more flexibility, see the bug
description.
Implementation wise, we already expose
On 1/14/19 10:23 AM, Boris Zbarsky wrote:
On 1/14/19 12:58 PM, Mats Palmgren wrote:
Link to standard: https://drafts.csswg.org/css-logical/#propdef-padding-inline
Two quick questions on the spec:
1) 'padding-block-start' is defined as:
Value: <‘padding-top’>
while 'padding-block' is def
On 1/14/19 7:23 PM, Boris Zbarsky wrote:
Do you know whether this is purposeful or just a typo?
Dunno. It seems like a typo to me.
2) We are just implementing the padding shorthands for now, not the margin
ones?
Yes, but I should probably just add margin-block/inline while I'm at it...
Fil
On 1/14/19 7:23 PM, Boris Zbarsky wrote:
> On 1/14/19 12:58 PM, Mats Palmgren wrote:
>> Do other browser engines implement this? No,
>> https://wpt.fyi/results/css/css-logical/logical-box-padding.html
>
> Do they plan to? That is, is the spec reflecting some sort of general
> consensus?
They'r
On 1/14/19 12:58 PM, Mats Palmgren wrote:
Link to standard:
https://drafts.csswg.org/css-logical/#propdef-padding-inline
Two quick questions on the spec:
1) 'padding-block-start' is defined as:
Value: <‘padding-top’>
while 'padding-block' is defined as:
Value: <‘padding-left’>{1,2}
I
On 1/2/19 5:18 PM, James Graham wrote:
On 23/12/2018 10:59, Emilio Cobos Álvarez wrote:
web-platform-tests: Minimal parsing tests are being added to:
https://wpt.fyi/results/css/mediaqueries/test_media_queries.html
Unfortunately WPT has no way to test print preview or pagination right
now
On 23/12/2018 10:59, Emilio Cobos Álvarez wrote:
web-platform-tests: Minimal parsing tests are being added to:
https://wpt.fyi/results/css/mediaqueries/test_media_queries.html
Unfortunately WPT has no way to test print preview or pagination right
now so the rest of reftests are Gecko-only.
On 12/21/18 7:23 PM, Eric Shepherd (Sheppy) wrote:
I just now saw this; as both a developer and as a writer on the MDN docs
team, I can tell you this will really be fantastic to have, and I can’t
wait! Not having control over breaks makes a lot of layout fail, especially
when trying to use mult
I just now saw this; as both a developer and as a writer on the MDN docs
team, I can tell you this will really be fantastic to have, and I can’t
wait! Not having control over breaks makes a lot of layout fail, especially
when trying to use multiple columns or grids to do layout.
On December 7, 201
On Thu, Dec 13, 2018 at 1:14 AM Henri Sivonen wrote:
> I changed the limit to 4 MB.
SGTM.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Tue, Dec 11, 2018 at 10:08 AM Henri Sivonen wrote:
> How about I change it to 5 MB on the assumption that that's still very
> large relative to pre-UTF-8-era HTML and text file sizes?
I changed the limit to 4 MB.
--
Henri Sivonen
hsivo...@mozilla.com
_
On Tue, Dec 11, 2018 at 2:24 AM Martin Thomson wrote:
> This seems reasonable, but 50M is a pretty large number. Given the
> odds of UTF-8 detection failing, I would have thought that this could
> be much lower.
Consider the case of a document of ASCII text with a copyright sign in
the footer. I
This seems reasonable, but 50M is a pretty large number. Given the
odds of UTF-8 detection failing, I would have thought that this could
be much lower. What is the number in Chrome?
I assume that other local sources like chrome: are expected to be
annotated properly.
On Mon, Dec 10, 2018 at 11:2
On Thu, Nov 29, 2018 at 6:27 AM Emilio Cobos Álvarez
wrote:
> Sorry for the lag replying to this.
>
> On 11/13/18 4:35 PM, James Graham wrote:
> > On 11/11/2018 17:57, Emilio Cobos Álvarez wrote:
> >
> >> web-platform-tests: Test coverage for all the values is pre-existing.
> >> There's unfortuna
Sorry for the lag replying to this.
On 11/13/18 4:35 PM, James Graham wrote:
On 11/11/2018 17:57, Emilio Cobos Álvarez wrote:
web-platform-tests: Test coverage for all the values is pre-existing.
There's unfortunately little coverage in WPT, but a lot in our
selection and contenteditable test
Finally something what solving problem of missing "word-break: break-word"
(https://jsfiddle.net/ofgd83um/80/)
When it will be shipped to stable?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Finally something can slove problem of missing "word-break: break-word"
https://jsfiddle.net/ofgd83um/80/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 11/11/2018 17:57, Emilio Cobos Álvarez wrote:
web-platform-tests: Test coverage for all the values is pre-existing.
There's unfortunately little coverage in WPT, but a lot in our selection
and contenteditable tests.
Can we upstream some of these tests to wpt? I don't know if there
are/wer
On 11/12/18 2:36 AM, flor...@rivoal.net wrote:
On Monday, November 12, 2018 at 2:57:14 AM UTC+9, Emilio Cobos Álvarez wrote:
Summary: Unprefix the -moz-user-select property, so that it works
without the -moz- prefix.
We happen to be supporting the -webkit- prefixed version of the
property, bu
On Monday, November 12, 2018 at 2:57:14 AM UTC+9, Emilio Cobos Álvarez wrote:
> Summary: Unprefix the -moz-user-select property, so that it works
> without the -moz- prefix.
>
> We happen to be supporting the -webkit- prefixed version of the
> property, but other browsers support it also unprefi
I think it's great, please go ahead. I just gave a talk about the various
properties/values related to line breaking, and had multiple people tell me
they were so sad that overflow-wrap:anywhere wasn't implemented yet. So I
totally support implementing/shipping this.
Ah, my bad. Yes, if scripts are available, this is available. It doesn't
allow you to do anything new, aside from forcing a decode to start (which
you could do by adding the image to the DOM tree, assuming it is visible)
and knowing when the decode has completed. The usual content restrictions
will
On 11/7/18 11:15 AM, Andrew Osmond wrote:
This is simply a
new method for JS on image elements, so it should be unavailable.
Script can run in sandboxed iframes, depending on sandboxing flags.
It sounds like this feature is enabled by default in sandboxed iframes,
as long as script is enabled
On Fri, Nov 2, 2018 at 5:26 PM Emilio Cobos Álvarez
wrote:
> This is mostly to prevent compat headache in mobile, hopefully prevent
> other vendors from shipping new un-spec'd env variables, and encourage
> people to use the fallback value if new environment variables are added
> in the future.
>
Just a quick update: This new policy has now been made the new default in
Nightly in https://bugzilla.mozilla.org/show_bug.cgi?id=1492563.
On Fri, Sep 21, 2018 at 3:15 PM Steven Englehardt
wrote:
> Technical documentation for this is now available on MDN:
> https://developer.mozilla.org/en-US/do
On 10/17/18 3:04 PM, Tom Ritter wrote:
I believe that we fiddle these for Resist Fingerprinting; can you ensure
the new values are similarly fiddled?
Yeah, they reuse literally the same code path, so they also have the
same fiddling for RFP.
-- Emilio
-tom
On Tue, Oct 16, 2018 at 10:02 P
I believe that we fiddle these for Resist Fingerprinting; can you ensure
the new values are similarly fiddled?
-tom
On Tue, Oct 16, 2018 at 10:02 PM Emilio Cobos Álvarez
wrote:
> (Trying to be more disciplined about pinging dev-platform@ about
> web-exposed changes, a few other emails will come
The next step for removing XBL in marquee will be to put the content inside of
a UA Widget Shadow Root and then (ideally) drop the JS-implemented animation in
favor of CSS animation. I expect that should be enough to fix
https://bugzilla.mozilla.org/show_bug.cgi?id=306344.
Brian
> On Oct 14, 2
Happy to see this coming. I'm (honestly) sort of a fan of , in a
twisted sort of way. A fun reminder of the whimsy of the early days of the
web, and amusing to use in certain types of examples.
On Sun, Oct 14, 2018 at 8:30 PM Karl Dubost wrote:
>
>
> Le 13 oct. 2018 à 02:56, Brian Grinstead a é
Le 13 oct. 2018 à 02:56, Brian Grinstead a écrit :
> Summary: […] I intend to implement and ship HTMLMarqueeElement.
Very cool. And a support on that, from a webcompat standpoint of view, because
it seems a lot of Indian websites rely on it. The current implementation has
"performance" issues
On Saturday, October 13, 2018 at 9:21:35 PM UTC+9, Xidorn Quan wrote:
> Summary: A new value of text-transform to convert small Kanas to their
> full-size counterparts to increase legibility in the expense of accuracy,
> usually when font size is small, e.g. in ruby.
>
> Bug: https://bugzilla.mo
On 10/12/18 1:56 PM, Brian Grinstead wrote:
Summary: Motion is a key component of modern web design, and is the
premier...
Fire. The premier fire so we can have fire and motion [1].
Or maybe it's just a dumpster fire? ;)
The proposed change looks great to me.
-Boris
[1] https://www.joel
On 11/10/2018 6:03 PM, Tom Ritter wrote:
Are we bringing in a new third party library for this? (Seems like yes?)
Who else uses it/audits it? Does anyone else fuzz it? Is it in OSS-fuzz?
Are we fuzzing it?
How does upstream behave? Do they cut releases or do they just have
continual developm
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 exp
Yes, that's part of it. Further, now that Edge has shipped it we can
cause there to be a majority of vendors supporting it. Having WebP
supported by all of the browsers changes the weight we put on the
different advantages and disadvantages. For example, Firefox
supporting WebP will allow now allow
1 - 100 of 614 matches
Mail list logo
