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

On Wed, Mar 10, 2021, at 8:01 PM, Anne van Kesteren wrote: > That does seem unfortunate, but unless other browsers are interested > in picking this up, I think it will hurt us more to be different than > that it helps. I don't think we should make aligning with Chrome and > Safari conditional upon

Intent to prototype and ship: ruby-position: alternate

Summary: `ruby-position: alternate` is the new initial value of the `ruby-position` property, it allows ruby text container (rtc) to alternate automatically on line's side without needing to specify a different value for each rtc. This is a more useful value when multiple rtcs are present.

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

On Tue, Feb 23, 2021, at 12:59 AM, Emilio Cobos Álvarez wrote: > Standard: https://drafts.csswg.org/selectors/#user-pseudos > > Other browsers: No signal from other vendors, though we've shipped this > functionality for quite a while and the CSS working group considers it > useful, see

Re: Intent to Ship: [css-transforms-2] Individual Transform Properties (i.e. translate, rotate, scale)

On Fri, Nov 15, 2019, at 10:01 AM, Boris Chiou wrote: > *DevTools*: We don't support DevTools for individual transforms now. I think the current policy is that if it's worth devtools support, there should be a bug filed? Also it seems to me this is something indeed devtools should be able to

Re: Intent to ship: CSS Containment

On Tue, Mar 19, 2019, at 6:01 AM, Daniel Holbert wrote: > As of today (March 18th 2019), I intend to turn CSS Containment > on by default on all platforms, in > Firefox Nightly 68. It has been developed behind the > 'layout.css.contain.enabled' preference.

Duplicate dependency policy for Rust in mozilla-central?

Hi all, Recently I tried to build Firefox on cloud, and noticed that building Rust dependencies is now a significant part of it. Another thing I noticed is that, we have lots of duplicate Rust dependencies. I scanned Cargo.lock in the root and found that we have: * 2 versions of block-buffer

Re: Intent to Implement and Ship: The border-{start, end}-{start,end}-radius CSS properties

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

Re: PSA: Landing Rust code that warns is no longer ok

On Sat, Dec 15, 2018, at 9:44 PM, Emilio Cobos Álvarez wrote: > In https://bugzilla.mozilla.org/show_bug.cgi?id=1513009 I just landed a > patch so that warnings for non-third-party Rust code get reported as > errors in automation, and thus fail to build (also if you build locally > with

Re: Proposed W3C Charter: Web Fonts Working Group

On Fri, Nov 16, 2018, at 11:12 AM, L. David Baron wrote: > The W3C is proposing a revised charter for: > > Web Fonts Working Group > https://www.w3.org/Fonts/WG/webfonts-2018-ac.html > https://lists.w3.org/Archives/Public/public-new-work/2018Oct/0015.html > > This is proposing a new work

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

On Sat, Nov 3, 2018, at 2:32 AM, Kartikaya Gupta wrote: > Hello searchfox fans, > > Those of you working in Windows-only Rust and C++ code will probably > be happy to hear that as of today searchfox is indexing the > Windows-only bits of our codebase as well. Great, thank you! It was a big pain

Intent to implement and ship: text-transform: full-size-kana

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.mozilla.org/show_bug.cgi?id=1498148 Link to standard:

Intent to ship: scrollbar-color and scrollbar-width properties

As of Firefox 64, I intend to turn scrollbar-color and scrollbar-width properties on by default on all platforms. They have been developed behind pref "layout.css.scrollbar-colors.enabled" and "layout.css.scrollbar-width.enabled" respectively. Other UAs don't currently have plan to ship it,

Intent to ship: Unprefixed Fullscreen API

As of Firefox 64, I intend to turn on unprefixed Fullscreen API by default on all platforms. It has been developed behind the full-screen-api.unprefix.enabled preference. Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1269276 Unprefixed Fullscreen API has been enabled

Intent to ship: accept arbitrary webkit-prefixed pseudo-element in selectors

In Firefox 64, I intend to turn accepting arbitrary webkit-prefixed pseudo-element in selectors on by default on all platforms. It has been developed behind "layout.css.unknown-webkit-pseudo-element". WebKit and Blink have had this behavior for long. Bug to turn on by default:

Intent to implement: accept arbitrary webkit-prefixed pseudo-element in selectors

Summary: Treat "::-webkit-whatever-stuff" as valid CSS selectors. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1424106 Link to standard: * https://github.com/whatwg/compat/issues/103 * https://github.com/w3c/csswg-drafts/issues/2156 (previous discussion of this topic) Platform coverage:

Re: PSA: cbindgen will be required to build in the near future.

On Fri, Aug 17, 2018, at 10:19 PM, Emilio Cobos Álvarez wrote: > Adding support for general crates.io crates to be built this way and > appear somewhere on the objdir seemed way more build system hackery than > what I could do in a reasonable timeframe with my limited knowledge of > the build

Intent to implement and ship: flow-relative values for resize property

Summary: Add two values "block" and "inline" to resize property. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1464786 Link to standard: https://drafts.csswg.org/css-logical/#resize Platform coverage: All platforms Estimated or target release: 63 Preference behind which this will be

Intent to unship: overflow: -moz-scrollbars-* values

In bug 1481125[1], I'm going to put some moz-prefixed values of overflow shorthand property behind pref, and disable them by default on all channel. The values being unshipped are: * -moz-scrollbars-none * -moz-scrollbars-horizontal * -moz-scrollbars-vertical Their functionality can be fully

Intent to implement: CSS property scrollbar-width

Summary: scrollbar-width is a property to control the width (thickness) of scrollbars of an element. In my current implementation plan, it accepts three keywords: auto | thin | none. "thin" would generate a thinner scrollbar suitable for narrow container, and "none" would hide the scrollbar

Re: Intent to implement: Scrollbar color properties

On Thu, Jul 26, 2018, at 7:44 AM, Karl Tomlinson wrote: > Thanks very much for answering some of my questions for me. > > Xidorn Quan writes: > > > On Wed, Jul 25, 2018, at 6:29 PM, Karl Tomlinson wrote: > >> Is there a plan to avoid the contrast problems we have

Re: Intent to implement: Scrollbar color properties

On Wed, Jul 25, 2018, at 6:29 PM, Karl Tomlinson wrote: > Is there a plan to avoid the contrast problems we have mixing > document colors with system colors in other widgets? > > e.g. If one scrollbar color is specified by the document, then what ensures > that other parts of the scrollbar are

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

On Fri, Jul 13, 2018, at 7:08 AM, smaug wrote: > One thing to remember that some of the child processes will be more > important than others. For example all the processes used for browsing > contexts in > the foreground tab should probably prefer performance over memory (in > cases that is

Re: Intent to implement: Scrollbar color properties

On Tue, Jul 10, 2018, at 7:36 AM, Tantek Çelik wrote: > >> Platform coverage: Desktop > > > > Why not on mobile? > > Requires platform specific code that just hasn't been written (yet) > for mobile platforms. Actually I don't really have a plan to support the rendering part of scrollbar color

Intent to implement: Scrollbar color properties

Summary: Two CSS properties scrollbar-{face,track}-color to style scrollbars in a color by author. These properties intends to provide a more restricted feature set for controlling scrollbar styling than ::-webkit-scrollbar-* pseudo-elements shipped in WebKit and Blink, so that authors can

Re: Rust crate approval

On Mon, Jul 2, 2018, at 9:03 AM, Eric Rescorla wrote: > On Sat, Jun 30, 2018 at 9:35 AM, Lars Bergstrom > wrote: > > > On Fri, Jun 29, 2018 at 8:33 AM, Tom Ritter wrote: > > > > > > > > I know that enumerating badness is never a comprehensive solution; but > > > maybe there could be a wiki page

Re: Launch of Phabricator and Lando for mozilla-central

On Thu, Jun 7, 2018, at 12:57 AM, Mark Côté wrote: > Phabricator is a suite of applications, but we are primarily using the > code-review tool, called Differential, which will be taking the place of > MozReview and Splinter. Bug tracking will continue to be done with > Bugzilla, which is

Intent to unship: DOMAttrModified and DOMSubtreeModified event for changes via CSSOM

In bug 1460295[1], I intend to stop triggering DOMAttrModified event as well as the general event DOMSubtreeModified for changes on style attribute via CSSOM by default. This behavior will be controlled by a pref "dom.mutation-events.cssom.disabled" so that we can revert it if necessary. Blink

Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue

Given that you are unshipping this... probably we should uplift a pref switch to beta to make it unship in 61 directly, and then remove in 62. I think that's probably safer than not unshipping it in 61 but removing directly in 62. - Xidorn On Sat, May 12, 2018, at 7:30 PM, Emilio Cobos Álvarez

Re: Update on rustc/clang goodness

On Fri, May 11, 2018, at 10:35 AM, Anthony Jones wrote: > I have some specific requests for you: > > Let me know if you have specific Firefox related cases where Rust is > slowing you down (thanks Jeff [7]) > Cross language inlining is coming - avoid duplication between Rust > and C++

Re: Removing tinderbox-builds from archive.mozilla.org

Would removing those files affect the ability of mozregression to locate pushes of old regressions? - Xidorn On Wed, May 9, 2018, at 4:49 PM, ntho...@mozilla.com wrote: > We have approximately 400 TB of old files in the two directories > firefox/tinderbox-builds and mobile/tinderbox-builds on >

Re: Intent to implement: AudioWorklet

On Wed, May 2, 2018, at 11:34 PM, Tom Ritter wrote: > On Wed, May 2, 2018 at 5:11 AM, Robert O'Callahan > wrote: > > On Wed, May 2, 2018 at 9:21 PM, Karl Tomlinson wrote: > > > >> It seems that Chrome works around this by choosing to garbage > >> collect

Re: Hey! Can you please briefly try this test build...

FWIW, I always find that the easiest way to run some build is using mozregression's "Run a single build", which would take care of downloading, unpacking, and creating a new profile for it. In this case, you'd want to choose "try" and input changeset "b5a512aaef49". - Xidorn On Fri, Apr 20,

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

It's fine to embed this experiment in the product, and blog about it, but it's definitely not fine to have it enabled by default and send every DNS request to a third-party. I can understand that the intent must be good, and for better privacy, but the approach of doing so is not acceptable.

Re: Intent to require Node to build Firefox 61 and later

On Thu, Mar 1, 2018, at 11:23 AM, Nicholas Alexander wrote: > The requirement will likely be Node v8.9.4, the current LTS release. MozillaBuild currently provides Node v8.9.0. If you are going to require a version higher than that, probably it'd be better to coordinate with the A-team to

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

Re: New prefs parser has landed

On Fri, Feb 2, 2018, at 10:40 AM, Nicholas Nethercote wrote: > [*] One tricky question is what to do with syntax errors. The current > behaviour is here: > https://searchfox.org/mozilla-central/source/modules/libpref/Preferences.cpp#1000-1011. > It writes the error to the browser console, but if

Re: Intent to ship: Do not allow a http-auth prompt requested by an image resource loaded from a cross-origin

On Wed, Dec 6, 2017, at 01:25 AM, Dragana Damjanovic wrote: > Hi all, > > We have implemented this for a log time, but the pref was turned off. > I intend to switch on the pref for this in bug 1423146. > After the pref is switched a http-authentication dialog prompt will not > be > shown if it is

Re: Intent to ship: CSS Shapes Module Level 1 (partial)

On Thu, Nov 30, 2017, at 07:16 AM, Mats Palmgren wrote: > I think supporting only a subset of the valid values for a property > is problematic. > > CSS conformance rules says: > "[...] the user agent must parse the value according to the property > definition. This means that the user agent must

Re: Intent to unship: @-moz-document from content pages.

On Thu, Nov 30, 2017, at 03:53 AM, Emilio Cobos Álvarez wrote: > Hi again, > > In bug 1035091 I intend to remove support for the @-moz-document CSS > rule in content pages (more exactly in author stylesheets). > > The reasoning for this, apart from it being a non-standard mozilla-only > CSS

Re: Hiding 'new' statements - Good or Evil?

On Wed, Nov 29, 2017, at 12:56 AM, Eric Rescorla wrote: > On Mon, Nov 27, 2017 at 6:41 PM, Xidorn Quan <m...@upsuper.org> wrote: >> On Tue, Nov 28, 2017, at 11:45 AM, Eric Rescorla wrote: >> > On Mon, Nov 27, 2017 at 4:07 PM, smaug <sm...@welho.com> wrote: >&

Re: Hiding 'new' statements - Good or Evil?

On Tue, Nov 28, 2017, at 11:45 AM, Eric Rescorla wrote: > On Mon, Nov 27, 2017 at 4:07 PM, smaug wrote: > > And auto makes code reading harder. It hides important information like > > lifetime management. > > It happens easily with auto that one doesn't even start to think

Late Intent to unship: several internal CSS properties with Stylo

There are several CSS properties, which are supposed to be internal, unintentionally unshipped from web content with Stylo. We didn't notice that until we started looking at internal properties support in chrome. The properties already unshipped in Firefox 57 are: -moz-window-opacity

Re: Intent to unship: mozmm CSS unit.

On Mon, Nov 13, 2017, at 02:11 AM, Emilio Cobos Álvarez wrote: > Hi, > > In bug 1416564 I intend to remove the mozmm CSS unit. > > This unit is Mozilla-only, has no spec, and is unused in all our > codebase (except for two tests, one of those which tests the unit > itself). > > This unit was

Re: Intent to require Python 3 to build Firefox 59 and later

I'm happy hearing this. I would be interested on whether we are going to drop Python 2 at some point, or are we stuck with that forever? Also I'm curious what modern features are the team looking forward to? - Xidorn On Sat, Nov 11, 2017, at 10:27 AM, Gregory Szorc wrote: > For reasons outlined

Re: Visual Studio 2017 coming soon

On Thu, Oct 26, 2017, at 12:24 PM, Ted Mielczarek wrote: > On the other hand, it's easier to > justify dropping support if VS is the last compiler holding us back from > being able to use new C++ features. FWIW, it's not at the moment. Currently we are really only blocked on GCC for new C++

Re: Intent to unship: :-moz-system-metric pseudo-class and media queries in content pages.

On Sat, Sep 2, 2017, at 06:06 AM, Emilio Cobos Álvarez wrote: > Hi dev-platform@, > > I'd like to unship access to the :-moz-system-metric pseudo-class, and > the system metric media queries, from content pages. I just filed > for that. > >

Re: Coding style question: Meaningless argument names in declarations

On Fri, Sep 8, 2017, at 01:16 AM, Emilio Cobos Álvarez wrote: > This is very context dependent, I'd never omit a name in a function that > takes (Element& aParent, Element& aChild), but it seems reasonable to > omit it in the case where there's no better name, like (InsertionKind > aInsertionKind)

Re: More Rust code

On Mon, Jul 10, 2017, at 08:29 PM, Nicholas Nethercote wrote: > Firefox now has multiple Rust components, and it's on track to get a bunch > more. See https://wiki.mozilla.org/Oxidation for details.> > I think this is an excellent trend, and I've been thinking about how to > accelerate it.

Re: Intent to unship: tree pseudo-element selectors from web content (::-moz-tree-*)

On Fri, Jul 7, 2017, at 03:55 PM, Frank-Rainer Grahl wrote: > Not using it but will this break remote XUL? XUL shouldn't be usable in content at all. Chrome document which have access to XUL should not be affected. - Xidorn ___ dev-platform mailing

Re: Intent to unship: tree pseudo-element selectors from web content (::-moz-tree-*)

On Fri, Jul 7, 2017, at 02:24 PM, Jet Villegas wrote: > It looks like there may be a lot more of these: > https://stackoverflow.com/a/25397485 > > How about we just stub out the Stylo impls instead of unshipping the pseudo > in content? I'm not unshipping this for Stylo... I just don't feel

Re: Intent to unship: tree pseudo-element selectors from web content (::-moz-tree-*)

On Fri, Jul 7, 2017, at 01:42 PM, Jet Villegas wrote: > Thanks for cleaning this up. > > On Thu, Jul 6, 2017 at 8:29 PM, Xidorn Quan <m...@upsuper.org> wrote: > > > Although they don't currently match anything on web content, there is > > still some risk for unshi

Intent to unship: tree pseudo-element selectors from web content (::-moz-tree-*)

I intent to unship tree pseudo-element selectors from web content in bug 1379031 [1]. This includes the following pseudo-elements: ::-moz-tree-column ::-moz-tree-row ::-moz-tree-separator ::-moz-tree-cell ::-moz-tree-indentation ::-moz-tree-line ::-moz-tree-twisty ::-moz-tree-image

Re: How can I run Firefox programatically in fullscreen?

On Tue, Jun 27, 2017, at 07:12 AM, Armen Zambrano Gasparnian wrote: > Asking around, looking on dxr or MDN did not yield something easily. > > I don't want to have to use Marionette in this specific automation > context. Firefox cannot / shouldn't start in full screen mode because it is tricky

Re: Intent to unship: xml:base attribute

On Wed, May 24, 2017, at 11:30 AM, Jet Villegas wrote: > xml:base (bug 1349024) has been removed in Nightly 55 for 2 months > now, and we haven't sen any reports of ill effects. Let's have this > testing expand to Beta 55, and on to Release if all goes well. Bug > 1350521 tracks this change riding

Intent to unship: Window.getDefaultComputedStyle

In bug 1355683 [1], I intent to unship Window.getDefaultComputedStyle function. This function is only implemented in Gecko. The corresponding spec added, then renamed, then removed this API. >From the investigation, this API is only used by jQuery [2], and jQuery uses feature detection since

Intend to unship: -moz-force-broken-image-icon property

I intend to remove the prefixed CSS property -moz-force-broken-image-icon in bug 1348208 [1], and add a new "browser.display.force_show_broken_image_placeholder" pref to replace it. This property is for forcing showing the image placeholder for broken images. It is initially added for making

Re: Should cheddar-generated headers be checked in?

On Mon, Feb 27, 2017, at 02:33 AM, Henri Sivonen wrote: > On Thu, Feb 23, 2017 at 4:37 PM, Ted Mielczarek > wrote: > > On Thu, Feb 23, 2017, at 06:40 AM, Emilio Cobos Álvarez wrote: > >> On Thu, Feb 23, 2017 at 08:25:30AM +0200, Henri Sivonen wrote: > >> > On Wed, Feb 22,

Re: Editing vendored crates

On Mon, Feb 27, 2017, at 09:10 AM, Bobby Holley wrote: > On Sun, Feb 26, 2017 at 9:51 AM, Henri Sivonen > wrote: > > > I tried to add some panics to a vendored to create (rust-encoding) to > > see if the code in question runs. However, I didn't get to the running > > part,

Intent to unship: "-moz-table-border-non-zero" pseudo-class outside UA stylesheet

Currently this prefixed pseudo-class is accessible everywhere, but it is actually only used in our UA stylesheet so far. In bug 1341925 [1], I'd like to restrict this pseudo-class to only be usable inside UA stylesheet. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1341925 - Xidorn

PSA: Putting at the start of header / source file may break Windows build

There is an issue [1] in our STL wrappers that, when is the first include in a source file, build would fail inside system header with MSVC. It doesn't always show up immediately when you do so because of unified source. But things may start being broken weirdly when someone tries to add new file

Re: Intent to unship: xml:base attribute

On Fri, Feb 17, 2017, at 01:38 AM, Ehsan Akhgari wrote: > On 2017-02-16 1:51 AM, Xidorn Quan wrote: > > Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=903372 > > > > Summary: > > * It has been removed from the spec years ago. > > * No other

Re: Intent to unship: xml:base attribute

On Fri, Feb 17, 2017, at 01:36 AM, Boris Zbarsky wrote: > On 2/16/17 7:12 AM, Xidorn Quan wrote: > > The perf penalty of xml:base is basically that we have to dynamically > > construct a URL from bottom to top along the tree whenever we need a > > base URL of an element. A

Re: Intent to unship: xml:base attribute

On Thu, Feb 16, 2017, at 10:25 PM, Gijs Kruitbosch wrote: > On 16/02/2017 06:51, Xidorn Quan wrote: > > Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=903372 > > > > Summary: > > * It has been removed from the spec years ago. > > * No other browser supp

Intent to unship: xml:base attribute

Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=903372 Summary: * It has been removed from the spec years ago. * No other browser supports it. * We pay performance penalty for it. * It makes things trickier for stylo to handle URL values. The tricky thing is that

Re: Intent to implement: CSS text-justify property

On Fri, Feb 10, 2017, at 12:33 AM, Patrick Brosset wrote: > > > > DevTools bug: It's not yet clear to me whether specific DevTools work will > > be needed. > > > > I don't think we need anything now, the property should work in the > inspector's Rules panel just like other properties. > Although

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On Fri, Feb 10, 2017, at 04:29 AM, Benjamin Smedberg wrote: > Will this also prevent loading downloaded .swf files into Firefox? This > is > > useful for running Flash games, which tend to work best in the browser > > (some media players also support loading Flash files, but their hotkeys > > tend

Re: test

Sorry for the noisy... It was meant to test whether the mailing list works again... But I picked the wrong email address so it got published. Please ignore this one. - Xidorn On Fri, Feb 10, 2017, at 01:44 PM, Xidorn Quan wrote: > This is for testing purpose, and should not be publis

test

This is for testing purpose, and should not be published to the list. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: support "basic shapes" for the CSS 'clip-path' property

On Tue, Feb 7, 2017, at 08:00 PM, Boris Zbarsky wrote: > On 2/7/17 3:03 AM, Ku(顧思捷)CJ wrote: > > https://drafts.fxtf.org/css-masking-1/#the-clip-path > > https://drafts.csswg.org/css-shapes-1/#supported-basic-shapes > > How stable are these specs? They don't seem to be anywhere near CR, and

Intent to ship: new syntax of rgb(), rgba(), hsl(), and hsla() functions in CSS

Summary: The change we are shipping includes: * making rgb() and hsl() accept an optional alpha value * making rgb() and hsl() accept new whitespace-separated syntax e.g. rgb(0 0 0 / 100%) * making rgba() and hsla() alias of rgb() and hsl() correspondingly (Please correct me if I was wrong, since

Re: Intent to Experiment: CSS Houdini Paint API Level 1

Great news! I guess that may also mean billm's bug 1308039 [1] which tried to do painting during GC (which will be backed out soon [2] because of lots of breakage) may never get chance to land anymore, since this API means it is expected to run JS code during painting. [1]

Re: Introducing mozilla::Result for better error handling

On Thu, Jan 5, 2017, at 03:28 PM, Cameron McCormack wrote: > On Tue, Dec 20, 2016, at 09:46 PM, Jan de Mooij wrote: > > A few weeks ago we added mozilla::Result to MFBT [0][1]. I was > > asked > > to inform dev-platform about this, so here's a quick overview. > > mozilla::Result is

Re: Intent to implement and ship: CSS caret-color property

On Sat, Dec 24, 2016, at 11:59 PM, Gijs Kruitbosch wrote: > On 24/12/2016 01:24, Ehsan Akhgari wrote: > > On 2016-12-23 8:13 PM, Xidorn Quan wrote: > >> I don't think that would be a problem, because the number of people who > >> use navigation caret is rather limi

Re: Intent to implement: HTML5 element

On Fri, Dec 23, 2016, at 02:33 PM, Tim Nguyen wrote: > Non-modal dialogs should just work fine in a chrome window (the dialog > would just be like a centered absolute positioned div). As for modal > dialogs (eg. dialogs that makes everything else inert), it would depend > on > whether the current

Re: Intent to implement and ship: CSS caret-color property

On Sat, Dec 24, 2016, at 04:32 AM, Ehsan Akhgari wrote: > Gecko supports a navigation mode caret which can be activated by > pressing F7 or Preferences -> Advanced -> General -> Always use the > cursor keys to navigate within pages. > > The spec does mention this, but I can’t figure out what it’s

Re: Intent to implement and ship: CSS caret-color property

On Wed, Dec 21, 2016, at 11:42 PM, Manuel Rego Casasnovas wrote: > Hi, > > just a small clarification regarding tests: > > On 21/12/16 01:17, Xidorn Quan wrote: > > Tests - URLs / paths to tests (preferably web-platform-tests) > > CSSWG's test repo contains so

Re: Intent to implement: HTML5 element

On Thu, Dec 22, 2016, at 05:41 AM, Joe Hildebrand wrote: > > On Dec 20, 2016, at 6:25 PM, Xidorn Quan <m...@upsuper.org> wrote: > > > >> So dialog.showModal() does not need to block script like other > >> modal APIs? > > > > > > Definitely n

Re: Intent to implement: HTML5 element

On Wed, Dec 21, 2016, at 12:23 PM, Ben Kelly wrote: > On Tuesday, December 20, 2016, Xidorn Quan <m...@upsuper.org> wrote: > > On Wed, Dec 21, 2016, at 11:12 AM, Mats Palmgren wrote: > >> Hi Tim, can you describe how the modality of dialog.showModal() > >>

Re: Intent to implement: HTML5 element

On Wed, Dec 21, 2016, at 11:21 AM, Tantek Çelik wrote: > I'm also curious how interactions between dialog.showModal() and then > controls inside of that going Fullscreen work (and then perhaps a > dialog inside that fullscreen view, etc.) That's a... good question. Per spec, it should just

Re: Intent to implement: HTML5 element

On Wed, Dec 21, 2016, at 11:12 AM, Mats Palmgren wrote: > Hi Tim, can you describe how the modality of dialog.showModal() works? > Does a web page have the power to block the user from interacting > with the entire browser (all windows)? Or is it just one window? > or just one tab? or something

Intent to implement and ship: CSS caret-color property

Summary: As the name indicates, it allows developers to change the color or caret. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1063162 Link to standard: https://drafts.csswg.org/css-ui-3/#insertion-caret Platform coverage: All platforms Estimated or target release: Firefox 53 Preference

Re: Intent to implement: OpenType Variation Fonts

On Tue, Dec 6, 2016, at 01:28 AM, Jonathan Kew wrote: > DevTools bug: It's not yet clear to me whether specific DevTools work > will be needed, beyond the support we'll automatically get for a new CSS > property. I think DevTools may want to display a panel which lists all available variation

Re: Upcoming rename of the marionette-client package to marionette-harness

Note that this kind of changes may lead to weird Python error. We have seen one in bug 1321468. If you recently see any unexpected Python error when running mach commands, try execute "./mach clobber python" first. ("./mach clobber" would *not* work because it only purges things inside the

No need to add "HTTP(..)" for reftests using fonts outside their directory

TL;NR - You don't need to use "HTTP(..)" directive on reftests to bypass same-origin policy, and you should not do so. - Historically, we added "HTTP(..)", "HTTP(../..)", etc. for downloadable fonts in reftests to bypass the strict same-origin policy of file protocol, which bans accessing

Re: Intent to implement: CSS initial-letter property

On Thu, Sep 29, 2016, at 04:04 PM, Jeremy Chen wrote: > Summary: Initial-letters have been widely used in typographic printing > for > long. However, it is not handy to put initial-letters on web pages. Web > developers/designers have suffered from doing massive math calculations > while laying

Re: Intent to ship: Storage API estimate method

On Wed, Sep 21, 2016, at 01:42 PM, Shawn Huang wrote: > Summary: > ​The Storage Standard defines an API for persistent storage and quota > estimates. > ​The estimate() > method can > be used to determine whether there is enough space

Re: mach and ccache failure?

On Sat, Aug 20, 2016, at 08:45 AM, zbranie...@mozilla.com wrote: > Both builds take around 43-46 minutes, with ccache hit rate 0.8-1.0%. > > This is the same source - mozilla-central from today. > > What am I doing wrong? Probably your ccache cache is too small? What size did you set? - Xidorn

Re: DXR: How to encourage people to link to perma-links instead of plain ones?

On Mon, Aug 8, 2016, at 11:35 PM, Boris Zbarsky wrote: > On 8/8/16 9:02 AM, Xidorn Quan wrote: > > Would that make it harder for people to jump into some file directly via > > history (or awesome bar)? > > I _think_ the suggestion is as follows: > > When you click

Re: DXR: How to encourage people to link to perma-links instead of plain ones?

On Mon, Aug 8, 2016, at 11:07 PM, Anne van Kesteren wrote: > On Mon, Aug 8, 2016 at 3:02 PM, Xidorn Quan <m...@upsuper.org> wrote: > > Would that make it harder for people to jump into some file directly via > > history (or awesome bar)? > > Yeah it might, I suppose

Re: DXR: How to encourage people to link to perma-links instead of plain ones?

On Mon, Aug 8, 2016, at 08:34 PM, Anne van Kesteren wrote: > On Mon, Aug 8, 2016 at 12:27 PM, Honza Bambas > wrote: > > Can we find some way to push users of DXR to use the correct permanent URL > > to link to? > > Use replaceState() and change the page UI to instead offer a

Re: Intent to ship: CSS4 :any-link pseudo-class

On Thu, Jul 28, 2016, at 02:13 AM, Boris Zbarsky wrote: > As of Firefox 50, Thomas intends to unprefix the CSS4 :any-link > pseudo-class by default on all platforms. FWIW, there is no CSS4. [1] It is just Selectors Level 4 :) [1] http://www.xanthir.com/b4Ko0 - Xidorn

Intent to Implement and Ship: AddEventListenerOptions.once

Summary: "once" is a new option for EventTarget.addEventListener (as a member of AddEventListenerOptions dictionary), which means that the added listener should only be invoked once. It is something libraries like jQuery have been providing for years. And it would make writing certain type of

Added --disable-e10s to mach run

Hi, In bug 1287069 (https://bugzil.la/1287069), I just landed a new command line argument, --disable-e10s, to |mach run|. As its name indicates, it would run the program with e10s disabled. This argument is effectively identical to setting pref "browser.tabs.remote.force-disable" to true, but as

Re: Checkin-needed requests - Please include complete information in the commit message :)

On Mon, Jul 11, 2016, at 04:26 PM, Martin Thomson wrote: > On Mon, Jul 11, 2016 at 2:18 PM, Xidorn Quan <m...@upsuper.org> wrote: > > I also use checkin-needed for small changes which I don't think it's > > worth to run a full testset for, to save some infra resources. &g

Re: Checkin-needed requests - Please include complete information in the commit message :)

On Mon, Jul 11, 2016, at 12:29 PM, Martin Thomson wrote: > Is now the right time to start talking about retiring checkin-needed, > or is it still heavily used? Isn't it still necessary for people who don't yet have permission to push? I also use checkin-needed for small changes which I don't

Re: Faster gecko builds with IceCC on Mac and Linux

On Wed, Jul 6, 2016, at 05:12 AM, Gregory Szorc wrote: > On Tue, Jul 5, 2016 at 11:08 AM, Steve Fink wrote: > > > I work remotely, normally from my laptop, and I have a single (fairly > > slow) desktop usable as a compile server. > > Gecko developers should have access to 8+

Re: Faster gecko builds with IceCC on Mac and Linux

I hope it could support MSVC one day as well, and support distribute any job to macOS machines as well. In my case, I use Windows as my main development environment, and I have a personally powerful enough MacBook Pro. (Actually I additionally have a retired MBP which should still work.) And if

Re: Making try faster for debugging intermittents

On Fri, Jul 1, 2016 at 1:02 PM, Karl Tomlinson wrote: > William Lachance writes: > > > As part of a larger effort to improve the experience around > > debugging intermittents, I've been looking at reducing the time it > > takes for common "try" workloads for developers (so

Re: PSA: Windows Defender can slow down builds and tests

Adding Firefox source directory to Windows Defender's exclusion list is the very first thing I do after I install the system. I also added the directory of MozillaBuild to the list, and the C++ compiler (cl.exe) to exclusion processes list. Not sure to what extend would that affect the build

Re: PSA: Removing the Pointerlock permission UI

On Wed, Jun 29, 2016 at 2:07 AM, Jonas Sicking wrote: > > Awesome! Do we have a restriction that pointerlock can only be entered > during a user action, like a click? > Yes. > And do we completely forgo the warning when the webpage is already in > fullscreen mode? > Yes,

  1   2   3   >