Re: Intent to ship: "object-fit" & "object-position" CSS properties

On 11/14/2014 05:30 PM, Kyle Huey wrote: > Does it make sense to wait a release (meaning one week on trunk) here? > Not judging this, just making sure you're aware of the dates. Thanks -- yup, I'm aware that we're branching soon. I don't think we'd gain much by holding off on this until the next

Re: PSA: Flaky timeouts in mochitest-plain now fail newly added tests

On 12/17/2014 01:27 PM, Martijn wrote: > What about where setTimeout is used as a fallback for when some event > failed to fire and the mochitest is stalled and the setTimeout is then > used to finish the mochitest on time and give some useful debug info? This exact scenario was called out in the

Re: PSA: Flaky timeouts in mochitest-plain now fail newly added tests

Sorry -- after re-reading, I realized I was wrong here -- your example scenario is actually different from the legitimate scenario I alluded to in the first message of this thread. The legitimate scenario from that first message was: - We're expecting that an event *will not* fire. - We wait a b

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

On 01/15/2015 09:46 AM, Chris Peterson wrote: > Another small benefit of optional non-unified builds is that clang does > a better job of reporting -Wunused-variable warnings with smaller > translation units. I assume that the number of identifiers in the > unified files exceed some clang analysis

Re: Intent to ship: CSS display:contents

Correct. Conceptually, the exists in the style tree (so e.g. your "text-align:center" style gets inherited to the h1, via the style system, and any other inherited properties or "div > * {" style rules would affect the children as well). But the does not exist in the box tree. It's replaced th

Re: Flexbox bug with word-wrap?

Fixed fiddle: http://jsfiddle.net/eum5bxub/4/ Basically what happens here is: (1) The text gets wrapped in an anonymous block, which is the flex item. (2) We run the flex algorithm, with 150px to divy up. We *try* to shrink that flex item, but we can't because it has (default) "min-width:auto"

Re: PSA: nsFrameList now supports range-based for loop

On 03/31/2015 02:59 PM, Xidorn Quan wrote: > I've landed bug 1143513 > which enables using > range-based for loop on nsFrameList. Now, when you want to iterate > nsFrameList, you no longer need nsFrameList::Enumerator. Just write: > > for (nsI

Re: IndexedDB transactions are no longer durable by default, and other changes

You've now sent 3 "please unsubscribe me" posts -- I don't think those have any effect, aside from spamming everyone else on the list. If you want to unsubscribe, you can do so via this link (which is included at the bottom of every email you receive from this list): https://lists.mozilla.org/l

Re: Misunderstood the "Assigned" at bugs! Sorry !!!

On 04/07/2015 01:15 PM, Tobias B. Besemer wrote: > OK, to reopen this discussion ... > > I suggested in Bug 1151371 to activate the status "IN_PROGRESS" in bmo and > use this status for bugs that are "in progress" ("patch in work") and that > everybody use the status "applied" in future only as

Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used

On 04/27/2015 12:48 PM, Ehsan Akhgari wrote: > I think we should > change it to require the usage of exactly one of these keywords per > *overridden* function: virtual, override, and final. Let me attempt to clarify why the "exactly one" requirement here is important. (It's non-obvious.) This ver

Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used

On 04/27/2015 01:47 PM, Daniel Holbert wrote: > BUT, if we add back the "virtual" keyword, we *lose some strictness*. In > other words, this is *not* equivalent to the versions above: > "virtual void foo() final" > Unless the formulations above, this version isn&

Re: Java Deployment Kit block

On 04/28/2015 04:16 PM, Dhon Buenaventura wrote: > Hi There, > > The block placed on the Java Deployment Kit seems to affect other plugins > such as Flash. I was using Nightly 64-bit as my web browser and have > observed that in the past few days, Adobe Flash seems to not work even > though I have

Re: Flexbox bug with absolutely positioned elements?

On 04/29/2015 03:06 AM, Amit Zur wrote: > http://jsfiddle.net/2ccvwjmr/1/ > Seems like DOM order has influence on the absolutely positioned element. I > don't think it's a desired behaviour. > Did I do anything wrong? Can you verify if this is a bug? It's correct according to an older version of

Re: Intent to deprecate: Insecure HTTP

On 05/04/2015 09:39 AM, Florian Bösch wrote: > Here is what I wrote that client: > > [...] For security reasons browsers want to disable fullscreen if you >> are not serving the website over HTTPS. Are you sure this is true? Where has it been proposed to completely disable fullscreen for non-HTT

Re: Intent to deprecate: Insecure HTTP

wrote: > > > On Tue, May 5, 2015 at 6:04 AM, Martin Thomson <mailto:m...@mozilla.com>> wrote: > > > > > On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert <mailto:dholb...@mozilla.com>> > > > wrote: > > > > (I think there&#

Re: Intent to implement and ship: document.execCommand("cut"/"copy")

On 05/05/2015 02:51 PM, Ehsan Akhgari wrote: > Sites such as Github currently use Flash in order to > allow people to copy text to the clipboard by clicking a button in their UI. Bugzilla does this, too! [1] (If you enable "experimental user interface" in your account's General Preferences.) Look

Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used

On 05/07/2015 02:53 PM, Karl Tomlinson wrote: > The warning that you are proposing to fix here is > -Woverloaded-virtual. [EDIT: karl meant to say > -Winconsistent-missing-override] > > At least once we can build with this warning enabled, I recommend > making this warning fatal instead of cover

Re: Use of 'auto'

On 06/02/2015 12:58 PM, smaug wrote: > So, I'd like to understand why people think 'auto' is a good thing to use. > (bz mentioned it having some use inside bindings' codegenerator, and > sure, I can see that being rather > valid case.) One common "auto" usage I've seen is for storing the result of

Re: The War on Warnings

On 06/04/2015 05:30 AM, Ehsan Akhgari wrote: > There are very good reasons for warnings to not cause tests to fail. We > have a lot of tests that are testing failure conditions that are > expected to warn, because they are failure conditions. Also: in layout, there are various warnings related to

Re: Private members of ref counted classes and lambdas

On 06/04/2015 07:29 AM, Andrew Osmond wrote: > Suppose I have some ref counted class Foo with the private member mBar. > Normally with a lambda expression, [...] > obviously the Foo object could get released before the dispatch > completes You may be interested in this thread from a few months bac

Re: The War on Warnings

On 06/04/2015 01:18 PM, smaug wrote: > More likely we need to change a small number of noisy NS_ENSURE_* macro > users to use something else, > and keep most of the NS_ENSURE_* usage as it is. I agree -- I posted about switching to something opt-in, like MOZ_LOG, for some of the spammier layout NS

Re: Intent to unship: -moz-prefixed CSS gradient functions

The un-shipping didn't stick this time, either. After just a few days of Nightly testing, we had three reports of significant breakage that were caused by this un-shipping (on zimbra[1], blogger[2], and a demo page for a webapp framework[1] which may have legacy instances deployed). So, I backed

Intent to ship: CSS Containment

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. Other UAs shipping this or intending to ship it are: * Chrome & o

Re: Intent to ship: CSS Containment

27;ll post a followup with answers to our other typical intent-to-implement fields, too. On Mon, Mar 18, 2019 at 12:07 PM James Graham wrote: > On 18/03/2019 19:01, Daniel Holbert wrote: > > As of today (March 18th 2019), I intend to turn CSS Containment > > <https://drafts.csswg.

Re: Intent to ship: CSS Containment

that Chrome doesn't restrict it, so it could conceivably create interop issues if we restricted it without getting them to also commit to restricting it. On Mon, Mar 18, 2019 at 12:39 PM Daniel Holbert wrote: > Yeah, sorry - our earlier intent-to-implement thread predated our current > bo

Re: Intent to ship: CSS Containment

On Mon, Mar 18, 2019 at 12:52 PM Daniel Holbert wrote: > Summary: > CSS Containment gives web developers several ways of indicating that a > subtree isn't influenced by the rest of the page. This may allow UAs to > perform certain optimizations that they otherwise would

Re: Intent to ship: CSS Containment

On Tue, Mar 19, 2019 at 2:13 AM Xidorn Quan wrote: > On Tue, Mar 19, 2019, at 6:01 AM, Daniel Holbert wrote: > > As of today (March 18th 2019), I intend to turn CSS Containment > > <https://drafts.csswg.org/css-contain/> on by default on all platforms, > in > > F

Re: Intent to ship: CSS Containment

Followup: it turns out this wasn't quite ready to be enabled for 68, so I'm now targeting Firefox 69 as the release where CSS Containment will be default-enabled in release. On Mon, Mar 18, 2019 at 12:01 PM Daniel Holbert wrote: > As of today (March 18th 2019), I intend to turn CS

Re: Intent to Prototype: text-decoration-skip-ink

On Wednesday, August 7, 2019 at 12:18:16 PM UTC-7, Tom Schuster wrote: > Very cool, I have been looking forward to this. I hope we can enable > this for links by default at some point, like Chrome. That's the plan! The new property here, "text-decoration-skip-ink", has the unusual distinction of

Intent to ship: CSS properties text-decoration-skip-ink, text-decoration-thickness, and text-underline-offset

As of today (Sept 12 2019), I've turned on support for the CSS properties text-decoration-skip-ink, text-decoration-thickness, and text-underline-offset, on all platforms. These features have been developed behind the preferences "layout.css.text-underline-offset.enabled", "layout.css.text-decorat

NS_ALWAYS_INLINE apparently needs to include "inline", or have "inline" alongside it everywhere

GCC 4.7 apparently complains if you specify the "always_inline" attribute without also specifying "inline", as observed in [1] and [2]. The exact warning is: # warning: always_inline function might not # be inlinable [-Wattributes] Right now, we define NS_ALWAYS_INLINE as __attribute__((alw

Re: NS_ALWAYS_INLINE apparently needs to include "inline", or have "inline" alongside it everywhere

peg's frequently-used INLINE keyword to NS_ALWAYS_INLINE[1] and hence trigger a lot of this problem there: ~Daniel [1] https://mxr.mozilla.org/mozilla-central/source/media/libjpeg/config.h#6 On 10/07/2012 01:38 PM, Daniel Holbert wrote: > GCC 4.7 apparently complains if you specify the &

Re: NS_ALWAYS_INLINE apparently needs to include "inline", or have "inline" alongside it everywhere

th the new-and-improved MOZ_ version. ~Daniel On 10/07/2012 01:38 PM, Daniel Holbert wrote: > GCC 4.7 apparently complains if you specify the "always_inline" > attribute without also specifying "inline", as observed in [1] and [2]. > The exact warning is: > >

Why are there "Android 4.0 opt" test runs on mozilla-central and nowhere else?

Mozilla-central TBPL has a row for "Android 4.0 opt", which isn't available on mozilla-inbound or on Try. I was under the impression that all the tests that get run on mozilla-central are supposed to also be run on Try and Inbound. Why is this not the case for these "Android 4.0 opt" tests? (Con

Re: jsm source (mercurial )

I'm guessing you meant "do_get_cwd" (not _workdir) That and do_print are defined in head.js: https://mxr.mozilla.org/mozilla-central/source/testing/xpcshell/head.js and they're documented here: https://developer.mozilla.org/en/docs/Writing_xpcshell-based_unit_tests ~Daniel On 01/06/2013 09:12 A

Re: Proposal to change the semantics of DONTBUILD

On 01/15/2013 01:20 PM, Gregory Szorc wrote: > This seems to make sense. My only concern is if there is a scenario > where you absolutely need to push without incurring a build (think merge > commit where you don't have control over the previous commits). I'm not > sure why we'd do that, so I'm inc

Re: printerenumeration (nsIPrinterEnumerator)

It looks like enumeratePrinters() was replaced by an attribute "printerNameList" in this changeset: https://hg.mozilla.org/mozilla-central/rev/d411716a02bc#l6.94 That attribute still exists on trunk, as shown here: https://mxr.mozilla.org/mozilla-central/source/widget/nsIPrintOptions.idl#64 Ho

Re: printerenumeration (nsIPrinterEnumerator)

uot;Zack Weinberg" wrote in message > news:r62dnejc_k946ptmnz2dnuvz_skdn...@mozilla.org... >> On 2013-01-30 2:23 PM, Daniel Holbert wrote: >>> >>> However, be warned that there are patches in bug 629500 to get rid of >>> nsIPrinterEnumerator entirely (though that b

<    1   2