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 cl
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 `DOMFiss
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 found)
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 a
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*: https://bugzilla.mozilla.org/show_bug.cgi?id=15585
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 a
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
> indicates
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 of
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 v
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 bet
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. T
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 they
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 than
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
go
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 cou
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.
nsT
19 matches
Mail list logo
