On Sat, Jul 6, 2019 at 2:44 AM Ehsan Akhgari wrote:
> Does the page need to include some of this description?
It has this:
# It's acceptable to merge the "intent to prototype" into the
# "intent to ship" email as long as all the relevant
# requirements are met.
I suppose it could be a little
On Fri, Jul 5, 2019 at 7:50 PM Masatoshi Kimura
wrote:
> On 2019/07/06 6:54, Andrew McCreight wrote:
> >> Here's an example of a crash report with DOMFissionEnabled:
> >>
> https://crash-stats.mozilla.org/report/index/dac0a91a-ad57-4446-9a82-505a80190705#tab-metadata
>
> I could not find
On 2019/07/06 6:54, Andrew McCreight wrote:
>> Here's an example of a crash report with DOMFissionEnabled:
>> https://crash-stats.mozilla.org/report/index/dac0a91a-ad57-4446-9a82-505a80190705#tab-metadata
I could not find `DOMFissionEnabled` in this crash report (although
`DOMIPCEnabled` is
On Wed, Jul 3, 2019 at 5:48 AM Anne van Kesteren wrote:
> Hi all,
>
> In consultation with others I have made some adjustments to
> https://wiki.mozilla.org/ExposureGuidelines.
>
> “Intent to implement” has been renamed to “Intent to prototype” to signify
> more clearly that the change does not
Hi everyone,
*Summary*: I'm planning to move the clear/captureEvents/releaseEvents no-op
methods as well as the all property from HTMLDocument to Document to bring
our implementation of these methods and property on par with the HTML spec.
*Bug*:
On Wed, Jul 3, 2019 at 8:45 PM Bryce Seager van Dyk
wrote:
> On Wednesday, July 3, 2019 at 2:27:30 PM UTC-7, Chris Peterson wrote:
> > On 7/3/2019 11:37 AM, Bryce Seager van Dyk wrote:
> > > I wanted to clarify, and discuss if needed, our styling of #define
> guards. My understanding is that we
On Fri, Jul 5, 2019 at 1:12 PM Andrew McCreight
wrote:
> I landed bug 1560977 a few days ago, so you can now see in a crash report
> if Fission was enabled. If it was, the "meta data" tab will have a value of
> 1 for DOMFissionEnabled. The behavior is modeled after DOMIPCEnabled which
>
dom/canvas has enabled -Werror=implicit-int-conversion since 68! :)
https://bugzilla.mozilla.org/show_bug.cgi?id=1540357
On Fri, Jul 5, 2019 at 11:15 AM Chris Peterson wrote:
>
> On 7/5/2019 10:39 AM, Gijs Kruitbosch wrote:
> >> FWIW once in a while I have come across bugs caused by truncation
I landed bug 1560977 a few days ago, so you can now see in a crash report
if Fission was enabled. If it was, the "meta data" tab will have a value of
1 for DOMFissionEnabled. The behavior is modeled after DOMIPCEnabled which
indicates when e10s is enabled. There is no explicit indicator if Fission
Hello!
Just wish to chime in with my 2c... Would the proposed shift towards
signed types only be for larger values (eg, >= 32 bits)?
Audio and rendering code would still require using unsigned types,
especially when packed into buffers. (eg, 8-bit unsigned color components,
32-bit packed RGBA
On 7/5/2019 10:39 AM, Gijs Kruitbosch wrote:
FWIW once in a while I have come across bugs caused by truncation of
integers where someone picked a specific size that was too small also,
e.g.
storing an offset into a text node in a 16-bit integer. I think that's
maybe something that's hiding
Hey folks,
The tree has been reformatted[0] using Prettier, and moving forwards we will
enforce the new JS coding style across the entire codebase. Central, inbound
and autoland will reopen shortly.
Rebasing
If you have any pending patches touching JS code, you’ll likely require to
rebase.
On 05/07/2019 17:36, Ehsan Akhgari wrote:
On Thu, Jul 4, 2019 at 8:05 AM Gerald Squelart
wrote:
- Our latest coding style [1] points at Google's, which has a section
about Integer Types [3], and the basic gist is: Use plain `int` for
"not-too-big" numbers
If you can 100% guarantee that
On Thu, Jul 4, 2019 at 8:05 AM Gerald Squelart
wrote:
> > > - Our latest coding style [1] points at Google's, which has a section
> about Integer Types [3], and the basic gist is: Use plain `int` for
> "not-too-big" numbers
> >
> > If you can 100% guarantee that they will not be too big, right?
On Fri, Jul 5, 2019 at 2:48 AM Jeff Gilbert wrote:
> Yes I intend to write precisely that, if we ban unsigned types.
> However I'm not really convinced that throwing out unsigned types is
> the right move.
>
Note that such a class, if it performs assertions, is actually completely
different
On Mon, Jul 1, 2019 at 8:54 PM Connor Brewster
wrote:
> Platform coverage: All platforms using the Gecko rendering engine
> (WebRender enabled only)
>
> Target release: Firefox 71 (WebRender enabled only)
>
> DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1561060
>
Hi Connor,
Since
Just a note: we have a new template for Intent to X here:
https://wiki.mozilla.org/ExposureGuidelines
In particular, this one looks like it has all the same
concerns/problems with filters being applied to sensitive third party
content, and attacks that use timing to read that content. Are these
On Fri, Jul 5, 2019 at 1:28 PM Nathan Froyd wrote:
>
> On Fri, Jul 5, 2019 at 2:48 AM Jeff Gilbert wrote:
> > It is, however, super poignant to me that uint32_t-indexing-on-x64 is
> > pessimal, as that's precisely what our ns* containers (nsTArray) use
> > for size, /unlike/ their std::vector
On Fri, Jul 5, 2019 at 2:48 AM Jeff Gilbert wrote:
> It is, however, super poignant to me that uint32_t-indexing-on-x64 is
> pessimal, as that's precisely what our ns* containers (nsTArray) use
> for size, /unlike/ their std::vector counterparts, which will be using
> the more-optimal size_t.
Yes I intend to write precisely that, if we ban unsigned types.
However I'm not really convinced that throwing out unsigned types is
the right move.
For instance, one of the optimizations mentioned in the linked video
seems to not mention that using (unsigned!) size_t instead of uint32_t
(like
20 matches
Mail list logo
