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 always_inline
-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:
# warning: always_inline function might
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?
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
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
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
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 bug seems to have stalled a
bit, so I don't know how soon that will happen).
It's blocked
Stepping back: [
This issue is really a special case of This patch compiles fine in my
local configuration, but it busts the build for $OTHER_PLATFORM.
The general solution to this class of problems is a try push, with
builds on at least one platform other than your local config (if not all
On 04/03/2013 04:56 PM, Daniel Holbert wrote:
Stepping back: [
This issue is really a special case of This patch compiles fine in my
local configuration, but it busts the build for $OTHER_PLATFORM.
The general solution to this class of problems is a try push, with
builds on at least one
Would this mean that Beta-channel users would see some features appear
on release-day, and then disappear a couple weeks later, and then those
same features (plus maybe some new ones) would suddenly reappear on the
next release day, and then potentially disappear again? (etc)
This seems like it
See also https://bugzilla.mozilla.org/show_bug.cgi?id=879275 , which bz
filed on (possibly, at some point) turning off support for -moz-box on
the web.
~Daniel
On 06/13/2013 08:56 PM, Robert O'Callahan wrote:
Bug 875060 made me wonder whether we should disable XUL 'display' values on
the Web,
This wiki page: https://wiki.mozilla.org/Features/Release_Tracking
now picks up on the keyword 'feature' in your meta/tracking bugs.
FWIW, our bugzilla instance currently has a definition for this keyword
that is Fennec-specific:
feature
Keyword to enable tracking new features for Fennec
On 11/15/2013 03:16 PM, ops...@gmail.com wrote:
adding either
export CXXFLAGS=-std=gnu++0x
or
export CXXFLAGS=-std=gnu++11
both seem to work. From Mozilla's perspective -- is one preferable?
FWIW, it looks like Mozilla uses the former (gnu++0x) in the build system:
On 11/22/2013 12:18 PM, Benjamin Smedberg wrote:
If you are writing code that wants to issue
warnings when methods fail, please either use NS_WARNING directly or use
the new NS_WARN_IF macro.
if (NS_WARN_IF(somethingthatshouldbetrue))
return NS_ERROR_INVALID_ARG;
if
On 01/06/2014 03:10 PM, Karl Tomlinson wrote:
Martin Thomson writes:
I would like to think that adding (or removing) braces from block statements
should be acceptable.
I would argue that braces should not be added with automation.
When debugging code, it is important to understand the
On 01/09/2014 03:33 AM, Neil wrote:
This does not apply to AssignLiteral on an nsString, since that used to
take a char ()[] parameter. Instead, consider assigning an
NS_LITERAL_STRING, or you can also use the new char16_t overload of
AssignLiteral by wrapping your string constant in
On 02/24/2014 08:25 AM, Sylvestre Ledru wrote:
By the way, do you have any plan to do the same with these libraries and
forward
the patches upstream?
I don't have concrete plans to do this, but others are welcome to!
It's often more difficult (with less immediate benefit) to fix warnings
in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2014 10:26 AM, Zack Weinberg wrote:
Does that mean a patch to squelch the uninitialized variable
warnings in layout will now be accepted? Those are the only
warnings in layout on my (Linux, debug) builds.
On 02/28/2014 05:32 PM, L. David Baron wrote:
Why not change the try repo reset procedure so that instead of just
cloning mozilla-central, you also pull from the old try repo into
the new one all of the heads of try pushes made within the last one
or two weeks. (Presumably there's a list of
On 04/01/2014 08:56 AM, Zack Weinberg wrote:
The downside of turning this on would be that any switch
statements that *deliberately* include only a subset of the
enumerators, plus a default case, would now have to be expanded to
cover all the enumerators. I would try it and report on how
On 03/07/2014 02:41 PM, Hal Wine wrote:
On 2014-02-28 17:24 , Hal Wine wrote:
tl;dr: what is the balance point between pushes to try taking too long
and loosing repository history of recent try pushes?
Based on the responses to this specific question, we'll go back to
waiting for developers
Hi dev-platform,
PSA: if you are adding a concrete class with AddRef/Release
implementations (e.g. via NS_INLINE_DECL_REFCOUNTING), please be aware
of the following best-practices:
(a) Your class should have an explicitly-declared non-public
destructor. (should be 'private' or 'protected')
classes to be final, C++11 type_traits
also has std::is_final for that.
Cheers,
Benoit
2014-05-28 16:24 GMT-04:00 Daniel Holbert dholb...@mozilla.com
mailto:dholb...@mozilla.com:
Hi dev-platform,
PSA: if you are adding a concrete class with AddRef/Release
implementations
On 06/03/2014 07:32 AM, Gabor Krizsanits wrote:
Currently m-c does not build with gcc 4.6 on ubuntu because something
similar. After
updating to 4.8 I got some warning in webrtc code, so I had to turn off
warning-as-errors.
FWIW, you can work around that with ac_add_options
On 06/03/2014 04:25 PM, Mike Hommey wrote:
As for warning-as-errors, it's not meant to be used for local builds,
because different compilers don't come with the same set of warnings.
I think that might be putting it a bit too strongly. Warnings-as-errors
absolutely *is* meant to be used with
On 07/10/2014 02:48 AM, Neil wrote:
Except for refcounted base classes (which as you note need to have a
protected virtual destructor), is there a correct style as to whether
the destructor should be private or protected and virtual or nonvirtual?
IMO, the destructor should be nonvirtual,
On 07/10/2014 08:03 AM, Benjamin Smedberg wrote:
On 7/10/2014 10:46 AM, Daniel Holbert wrote:
Shouldn't the refcounting still be on the concrete classes?
Why?
This happens for example with nsRunnable: nsRunnable does the
refcounting, and all the derivations of nsRunnable only have to worry
Summary: The 'object-fit' and 'object-position' properties allow web
developers to customize how a replaced element's content gets scaled and
positioned to fit the element's content-box. (i.e. how an image or a
video gets scaled/positioned inside of an img/video tag) The
'object-fit' property lets
On 09/10/2014 05:26 PM, Jonas Sicking wrote:
Yes!
Do we have a sense for how supportive other browser vendors are of
these properties?
Supportive! I haven't tested other browsers' implementations yet, but I
do know that it's been implemented in Blink, and it was apparently
undergoing
Summary: The CSS declaration image-rendering: pixelated allows authors
to request that we scale up images by effectively making the pixels
larger (using a nearest-neighbor algorithm). This is in contrast to
the default (non-pixelated) scaling behavior, which tends to blur the
edges between an
On 09/23/2014 02:16 PM, Ehsan Akhgari wrote:
Why are upscaling and downscaling treated differently for pixelated?
I'm not entirely sure what the origin of that distinction is, but my
understanding (mostly from reading Tab's comments/responses on the Blink
intent-to-implement thread) is that
On 09/23/2014 02:39 PM, Daniel Holbert wrote:
On 09/23/2014 02:16 PM, Ehsan Akhgari wrote:
Why are upscaling and downscaling treated differently for pixelated?
I'm not entirely sure what the origin of that distinction is, but my
understanding (mostly from reading Tab's comments/responses
On 09/23/2014 02:56 PM, Daniel Holbert wrote:
FWIW, I also emailed www-style to sanity-check my understanding to see
if there are any other reasons for this behavior-difference:
http://lists.w3.org/Archives/Public/www-style/2014Sep/0340.html
Turns out there wasn't a strong reason
On 09/23/2014 04:24 PM, Jonas Sicking wrote:
Would it make sense to have separate properties for scale up and
scale down? With image-rendering being a shorthand for setting both?
Firstly: per my replies on the subthread started by ehsan, the
distinction in scale up vs. scale down behavior has
On 09/23/2014 04:38 PM, Daniel Holbert wrote:
On 09/23/2014 04:24 PM, Jonas Sicking wrote:
Would it make sense to have separate properties for scale up and
scale down? With image-rendering being a shorthand for setting both?
Firstly: per my replies on the subthread started by ehsan
(Oh, I
On 09/23/2014 10:08 PM, Martin Thomson wrote:
On 2014-09-23, at 13:53, Daniel Holbert dholb...@mozilla.com wrote:
Link to standard:
http://dev.w3.org/csswg/css-images/#valuedef-pixelated
Reading the spec it doesn’t say anything about what to do when the image is
scaled up on one axis
On 09/23/2014 01:53 PM, Daniel Holbert wrote:
Link to standard:
http://dev.w3.org/csswg/css-images/#valuedef-pixelated
As noted elsethread (in my response to Martin), it looks like the
canonical definition of this property-value is actually in a different
ED -- the level 3 ED. (whereas the link
On 09/23/2014 10:30 PM, Daniel Holbert wrote:
As noted elsethread (in my response to Martin), it looks like the
canonical definition of this property-value is actually in a different
ED -- the level 3 ED. (whereas the link above is currently the level
4 ED).
(This change -- moving the image
On 09/24/2014 07:38 AM, Ehsan Akhgari wrote:
This makes the implementation considerably simpler, which is great. It
also means that pixelated will essentially just be a
more-interoperable version of -moz-crisp-edges, for the time being.
So, what are we planning to do with -moz-crisp-edges?
On 09/24/2014 09:32 AM, L. David Baron wrote:
Or, alternatively, it seems like the use case here would be
addressed by doing what the spec said before.
Following up more on this: the CSSWG has now resolved to *allow* (but
not require) the formerly-required-by-spec prettier downscaling
On 09/24/2014 06:26 PM, Ehsan Akhgari wrote:
Hmm, doesn't that basically allow non-interoperable implementations? :(
I think Jonas' idea on having separate properties for the upscale vs.
downscale cases is much better.
I'm unconvinced about the usefulness of exposing that much control. This
On 09/24/2014 09:23 PM, Daniel Holbert wrote:
So, it's not required to behave exactly the same everywhere; it simply
codifies an author's intent. (OK, I suppose it *is* required to behave
exactly the same everywhere in the case of pixelated upscaling,
since that requires a particular
On 09/25/2014 09:16 AM, Ehsan Akhgari wrote:
No, sorry for not being clear, I didn't mean pixel for pixel identical
results. My question was: are we going to have the same behavior for
pixelated in the downscaling case, since now the spec allows two
different behaviors for that case.
Gotcha.
On 09/25/2014 08:24 AM, James Graham wrote:
So, are we sure that this is what the spec *should* say? can we imagine
a scenario in which authors either use hacks to specify different
properties for different browsers
Bad news: we are already in that world. Right now, if authors want
pixelated
On 10/09/2014 02:39 AM, yio...@gmail.com wrote:
Which version of the official opening?
It's looking like object-fit object-position will be released in
Firefox 36, if that's what you're asking.
You can follow along on the bug page:
https://bugzilla.mozilla.org/show_bug.cgi?id=624647
This is
On 09/25/2014 10:29 AM, Ehsan Akhgari wrote:
I don't see this temporary difference as particularly problematic,
particularly given that pixelated is primarily an upscaling feature,
and given that we'll match them before too long. But if others
disagree, I'm open to holding off on shipping
This is known/expected fallout from a spec change. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1043520 for other trouble
that it's caused. :-/
tl;dr: you need to set min-height:0 on the 'section' to get the
behavior you want. Here's the fixed version:
http://jsfiddle.net/vyhf2rzL/2/
On 11/10/2014 01:44 AM, Josip Maras wrote:
How can I build a normal, standard Firefox installer for Windows,
like the one distributed to standard Firefox users?
I don't know the answer to your specific question (I've never personally
had to build the installer), but just as a heads-up: you
As of sometime early next week (say, Nov 17th 2014), I intend to turn on
support for the object-fit object-position CSS properties by default.
They have been developed behind the
layout.css.object-fit-and-position.enabled preference. (The layout
patches for these properties are actually just
Here's the intent to ship thread, for reference:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/DK_AyuGfFhg
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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
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
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
Correct.
Conceptually, the div 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 div does not exist in the
box tree. It's replaced
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,
On 03/31/2015 02:59 PM, Xidorn Quan wrote:
I've landed bug 1143513
https://bugzilla.mozilla.org/show_bug.cgi?id=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 (nsIFrame*
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):
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 it
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
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 verbose
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-HTTPS
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 covering
...@mozilla.com
mailto:m...@mozilla.com wrote:
On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert dholb...@mozilla.com
mailto:dholb...@mozilla.com
wrote:
(I think there's a strong case for disabling *persistent* fullscreen
permission, for the reasons described
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 taken or as
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
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 back:
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
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 a
On 09/01/2015 09:56 AM, Richard Barnes wrote:
> # Compatibility impact
>
> Disabling RC4 will mean that Firefox will no longer connect to servers that
> require RC4. The data we have indicate that while there are still a small
> number of such servers, Firefox users encounter them at very low
On 01/04/2016 12:19 AM, Daniel Holbert wrote:
> I wasn't able to
> remotely figure out what the piece of spyware was or how to remove it --
> but the rejected certs reported their issuer as being "Digital Marketing
> Research App" (instead of e.g. Digicert or Verisign). Goo
For reference, I've now filed a bug to cover outreach for the specific
tool that this user was using:
https://bugzilla.mozilla.org/show_bug.cgi?id=1236664
I'm also trying to get my hands on the software, but it's "invitation
only", so that may prove difficult.
~Daniel
On 01/04/2016 10:33 AM, Josh Matthews wrote:
> Wouldn't the SSL cert failures also prevent submitting the telemetry
> payload to Mozilla's servers?
Hmm... actually, I'll bet the cert errors will prevent Firefox updates,
for that matter! (I'm assuming the update-check is performed over HTTPS.)
So
On 01/04/2016 12:07 PM, Daniel Holbert wrote:
> UPDATE: in my family friend's case, the shoddy MITM spyware in question
> was "Simmons Connect Research Application", a consumer profiling tool
> that's tied to Experian which users can voluntarily install in exchange
> for p
Heads-up, from a user-complaint/ support / "keep an eye out for this"
perspective:
* Starting January 1st 2016 (a few days ago), Firefox rejects
recently-issued SSL certs that use the (obsolete) SHA1 hash algorithm.[1]
* For users who unknowingly have a local SSL proxy on their machine
from
On 12/31/2015 11:37 AM, Martin Thomson wrote:
> If we intend to continue to support these,
(We do.)
> and particularly if we
> anticipate more prefixed rules in future
(Happily, I don't anticipate too many more of these -- at least, the
space of -webkit-prefixed features is bounded, because
On 12/31/2015 01:15 PM, Daniel Holbert wrote:
> (1) Dubious effectiveness:
[...]
> (2) Dubious usefulness: Given that these prefixed features will now
> Just Work in Firefox, and given that we're saying they're de-facto part
> of the web & committing to supporting them (and
Summary:
A good chunk of the web today (and particularly the mobile web)
effectively relies on -webkit prefixed CSS properties & features. We
wish we lived in a world where web content always included
standards-based fallback (or at least multiple-vendor-prefixed
fallback), but alas, we do not
On 01/04/2016 09:47 AM, Eric Rescorla wrote:
> I believe that Chrome will be making a similar change at a similar time
>
> -Ekr
In contrast, it looks like IE & Edge will continue accepting SHA1 certs
on the web for another full year, until 2017. [1][2]
~Daniel
[1]
On 01/04/2016 10:21 AM, Adam Roach wrote:
> I propose that we minimally should collect telemetry around this
> condition. It should be pretty easy to detect: look for cases where we
> reject very young SHA-1 certs that chain back to a CA we don't ship.
> Once we know the scope of the problem, we
On 01/04/2016 10:18 AM, Eric Rescorla wrote:
> I believe you are confusing two different things.
>
> 1. Whether the browser supports SHA-1 certificates at all.
> 2. Whether the browser supports SHA-1 certificates signed after Jan 1 2016
> (The CA/BF Baseline Requirements forbid this, so no
We still have documentation on MDN with the old rules:
"The uuid must be changed anytime any part of the
interface or its ancestors are changed"
https://developer.mozilla.org/en-US/docs/Mozilla/XPIDL#Interfaces
Ehsan, could you update that section of the page to reflect the new
state of the
On 02/12/2016 11:02 AM, Armen Zambrano G. wrote:
> On 16-02-09 01:32 PM, Daniel Holbert wrote:
>> Just to clarify, you're *only* talking about browser-chrome mochitests
>> here, correct? (not other mochitest suites like mochitest-plain)
>>
>> (It looks like this is
On 04/08/2016 10:38 AM, Jip de Beer wrote:
> I didn't manage to dump the Frame Tree using lldb... I followed these guides:
[...]
> I tried with Firefox, FirefoxDeveloperEdition and the nightly build (ran lldb
> from Terminal as well as Xcode).
> I was able to attach lldb to the browser, but not
On 04/08/2016 02:55 PM, Daniel Holbert wrote:
> On 04/08/2016 10:38 AM, Jip de Beer wrote:
>> I didn't manage to dump the Frame Tree using lldb... I followed these guides:
> [...]
>> I tried with Firefox, FirefoxDeveloperEdition and the nightly build (ran
>> lldb from T
On 03/21/2016 10:38 PM, Jet Villegas wrote:
> I'd like to see this guarded by its own pref && layout.css.prefixes.webkit
Pushing back on this slightly:
- At this point, I don't think it's conceivable that we'd want to ship
our webkit compatibility work until we're ready to also ship support for
On 03/22/2016 02:16 PM, Mike Taylor wrote:
> +1. It has been nice to have a single pref to flip to test for potential
> regressions (and for instructing people to do the same thing).
That's probably not a big concern here -- even if we ship this with its
own dedicated feature-pref, we could still
On 03/22/2016 04:53 PM, Jet Villegas wrote:
> I'm thinking we need two prefs so we cover the prefixed and unprefixed
> API as per:
> https://lists.w3.org/Archives/Public/www-style/2016Mar/0283.html
>
> It's a bit odd to have the -webkit parser pref also control the
> rendering pref in this case.
On 12/30/2015 10:40 PM, Daniel Holbert wrote:
> Estimated or target release:
> Firefox 46 (current Nightly), or 47 if we need to hold it back a
> release to fix things.
>
> Preference behind which this will be implemented:
> layout.css.prefixes.webkit
Following up on th
On 05/13/2016 10:49 AM, Jet Villegas wrote:
> If I'm reading the dependency list correctly, we still plan to uplift to
> 48 if we can get bug 1264905 fixed in time. Is that correct?
bug 1264905's fix (a pref-unguarding) was just landed, as well.
We could uplift both, if we *also* uplift bug
On 04/14/2016 02:40 AM, Ms2ger wrote:
>> Preference behind which this will be implemented:
>> layout.css.prefixes.webkit
>
> Should this have a more specific pref?
Absent a compelling reason, no -- it should not.
We're using layout.css.prefixes.webkit here because, without this
On 07/25/2016 07:11 AM, Ms2ger wrote:
> Hey Jonathan,
[...]
> Do we know how other vendors feel about this?
Sentiment seems to be positive.
Browser vendors are collaborating on developing the Houdini specs, and I
haven't heard any serious reservations on this spec. (This is among the
more
On 08/08/2016 10:12 AM, Daniel Holbert wrote:
> The fix in Firefox should be a pretty simple change, I think, but
> unfortunately we haven't gotten to it yet. I can prioritize it to fix
> in the next week or so, though that still means it wouldn't reach
> Firefox release users for
ship in a near nightly?
>
> On Sunday, August 7, 2016 at 10:23:01 PM UTC+3, Daniel Holbert wrote:
>> Firefox's behavior on that testcase matches an older version of the spec
>> (and then the spec changed).
>>
>> This bug...
>> https://bugzilla.mozilla.
Firefox's behavior on that testcase matches an older version of the spec
(and then the spec changed).
This bug...
https://bugzilla.mozilla.org/show_bug.cgi?id=1000957
...is filed on bringing us up-to-date on that point.
~Daniel
On 08/07/2016 05:16 AM, Amit Zur wrote:
> Hey,
>
> Take a look
On 1/3/17 4:48 PM, ktecrami...@gmail.com wrote:
>> e.g. It seems like introductory notes example could just use a
>> separate SVG element that had fixed positioning instead of needing to build
>> fixed-position into SVG.
>
> By "introductory notes example" do you mean the example in following
Just a heads-up, for anyone working on layout / style-system-related code:
In bug 1293739 [1], Jonathan Chan has some patches that will rename the
enumerated type "nsCSSProperty" to now be named "nsCSSPropertyID"
(adding the "ID" suffix). I plan on landing his patches on inbound later
today.
On 08/12/2014 07:59 AM, Benjamin Smedberg wrote:
> But now that nsCOMPtr/nsRefPtr support proper move constructors, [...]
> Could we replace every already_AddRefed return value with a nsCOMPtr?
I have a variant of bsmedberg's original question here. He asked about
return values, but I'm
On 09/12/2016 12:22 PM, Boris Zbarsky wrote:
> It's worse than that. For a wide range of callers (anyone handing the
> ref across threads), the caller must check immediately whether the
> callee actually took the value and if not make sure things are released
> on the proper thread...
Ah, ok; I
On 09/12/2016 11:00 AM, Boris Zbarsky wrote:
> On 9/12/16 1:53 PM, Daniel Holbert wrote:
>> (I believe we have the "already_AddRefed as a parameter" pattern in our
>> code in order to avoid an extra addref/release when ownership is being
>> transferred into
On 10/07/2016 12:49 AM, Gian-Carlo Pascutto wrote:
> This behavior can be controlled via a pref:
> pref("security.sandbox.content.level", 2);
>
> Reverting this to 1 goes back to the previous behavior
Warning: don't actually try to revert this to 1, just yet -- at the
moment, that triggers
1 - 100 of 119 matches
Mail list logo
