Re: Use of C++11 std::unique_ptr for the WOFF2 module

[Frédéric WANG]

Le 01/02/2016 23:38, Nathan Froyd a écrit :
> We're working on moving all of our platforms to use a C++11-ish
> standard library.  For std::unique_ptr, at least, the best tack is to
> write a small polyfill based on mfbt/UniquePtr.h.  (It's not clear to
> me how your suggestion with std::vector applies here.)  If our
> UniquePtr isn't a drop-in replacement for std::unique_ptr, that's
> worthy of a bug report.
>
> -Nathan
Yes, Lee Salzman gave me such a suggestion (thanks btw).

Regarding my suggestion of std::vector: One file in the WOFF2 library is
implementing the optimization of OpenType tables and has to manipulate
list of points. In previous version this was done using
std::vector. For some reason, in the latest upstream version it
is now done via a std::unique_ptr. So what I've done is just to
go back to the previous implementation. Of course, this only applies to
this particular case and is not a general replacement for std::unique_ptr

Using UniquePtr or a polyfill base on UniquePtr will probably gives a
result closer the author's intention. But at the end we will still have
to patch the woff2 library in some way...

-- 
Frédéric Wang




signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use of C++11 std::unique_ptr for the WOFF2 module

[Ehsan Akhgari]

On 2016-02-01 5:38 PM, Nathan Froyd wrote:

On Mon, Feb 1, 2016 at 4:29 AM, Frédéric Wang  wrote:


I tried updating the source code of WOFF2 to the latest upstream
version. Unfortunately, try server builds fail on OSX and mobile devices
because the C++11 class std::unique_ptr does not seem to be available.
IIUC some bugzilla entries and older threads on this mailing list, at
the moment only some of the C++11 features are usable in the mozilla
build system. Does any of the build engineer know whether
std::unique_ptr can be made easily available? Or should we just patch
the WOFF2 library to use of std::vector (as was done in earlier version)



We're working on moving all of our platforms to use a C++11-ish standard
library.  For std::unique_ptr, at least, the best tack is to write a small
polyfill based on mfbt/UniquePtr.h.


Yeah, this seems like a good interim solution.  We already have one 
example of this, and perhaps we should be doing more of it, so that 
people can just use the standard names.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: Opus audio in mp4

[Ralph Giles]

We intend to support the Opus audio codec in mp4 fragments and files.

Opus is a royalty-free audio compression format developed by Mozilla
(Xiph), Microsoft (Skype), Broadcom and others. It offers better
quality for both voice and music, scaling over a wider range of
network speeds and with lower latency than previous codecs. It's been
in Firefox for several years and on its own is a manditory part of the
WebRTC specification.

MP4 is the most widely used video format on the web today.

Combining the two will give us a way to record and play back
interactive WebRTC streams with Opus audio and h.264 video, which
currently doesn't work because they have different container supports.

We also hope to make it easier for site authors to take advantage of
better compression technology by reducing migration barriers for
established code based on the mp4 container.

The plan is to support this through the mp4 parser rewrite Matthew
Gregan and I are doing in the rust programming language, so
availability will be gated by --enable-rust as well as a pref, likely
media.mp4.opus.enable. Currently that would limit it to official
builds on MacOS X and 64-bit Linux, but I hope there will be more
soon.

We do not have a target release for this yet. Whenever we feel the
specification is sufficiently stable.

More about Opus at https://opus-codec.org/
Draft spec at https://opus-codec.org/docs/opus_in_isobmff.html


Comments welcome,
 -r
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Martin Thomson]

On Tue, Feb 2, 2016 at 10:42 AM, Milan Sreckovic  wrote:
> Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit 
> Windows.  If I’m reading the data correctly, more than half.  A small 
> percentage of those don’t have SSE2.

Do we have any, say telemetry, that would move this from speculation
into numbers?  Sure, numbers aren't necessarily perfect, but I'm sure
that they would help.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Chris Peterson]

On 2/1/16 3:56 PM, Mike Hommey wrote:
> 64-bits Firefox was only officially released recently, and AFAIK, we're not
> offering 32-bits Firefox users an upgrade to 64-bits Firefox if their
> system permits. How about we started doing that?

There are two steps planned to bring 64-bit Firefox to normal release users:

* A "universal" stub installer that downloads 32-bit or 64-bit Firefox,
depending on the user's OS, for new installs.

* Auto-upgrading existing 32-bit users to 64-bit.

This work was planned for 2016, but I don't know the current state.

The primary concerns are NPAPI plugins and add-on compatibility. We only
support Flash and Silverlight on 64-bit Firefox. If a user doesn't have
any other plugins installed, or if they haven't used their other plugins
in N months, perhaps they could be upgraded without problem.


chris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Xidorn Quan]

On Tue, Feb 2, 2016 at 11:09 AM, Nicholas Nethercote
 wrote:
> On Tue, Feb 2, 2016 at 10:55 AM, Xidorn Quan  wrote:
>>>
>>> Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit 
>>> Windows.  If I’m reading the data correctly, more than half.  A small 
>>> percentage of those don’t have SSE2.
>>
>> It's not surprising to me. We didn't have Firefox release for Win64 until 
>> recent,
>> and we haven't ever pushed users with 64bit Windows to use that version,
>
> There are three Windows configurations, AIUI:
>
> a) 32-bit Firefox on 32-bit Windows
> b) 32-bit Firefox on 64-bit Windows
> c) 64-bit Firefox on 64-bit Windows
>
> I think Milan is talking about (a) and Xidorn is talking about (b) vs. (c).
>
> This discussion will be more productive if everyone is clear about
> which configurations they mean. Thanks.

Thanks for making it clear, and sorry for misreading the email.

So Milan, did you mean there are over half of people using 32bit
Windows not just 32bit Firefox? Is there any data we can see for this?

Looked at Telemetry, and found an item called
DEVTOOLS_OS_IS_64_BITS_PER_USER, which according to the code, actually
checks whether the build is 64bit, not the system. (That checks
eventually goes to nsXULAppInfo::GetIs64Bit(), which returns value
depends on a compile time macro.)

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Nicholas Nethercote]

On Tue, Feb 2, 2016 at 10:55 AM, Xidorn Quan  wrote:
>>
>> Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit 
>> Windows.  If I’m reading the data correctly, more than half.  A small 
>> percentage of those don’t have SSE2.
>
> It's not surprising to me. We didn't have Firefox release for Win64 until 
> recent,
> and we haven't ever pushed users with 64bit Windows to use that version,

There are three Windows configurations, AIUI:

a) 32-bit Firefox on 32-bit Windows
b) 32-bit Firefox on 64-bit Windows
c) 64-bit Firefox on 64-bit Windows

I think Milan is talking about (a) and Xidorn is talking about (b) vs. (c).

This discussion will be more productive if everyone is clear about
which configurations they mean. Thanks.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Mike Hommey]

On Mon, Feb 01, 2016 at 06:42:30PM -0500, Milan Sreckovic wrote:
> 
> > On Feb 1, 2016, at 18:00 , Xidorn Quan 
> > wrote: ...
> > 
> > It seems to me if we do, whether enabling SSE2 on x86 doesn't really
> > matter unless we have a good reason. Fewer and fewer people would
> > stick on x86, especially who cares about performance.
> 
> Surprisingly, perhaps, there are a lot of people using Firefox on
> 32-bit Windows.  If I’m reading the data correctly, more than half.  A
> small percentage of those don’t have SSE2.

64-bits Firefox was only officially released recently, and AFAIK, we're not
offering 32-bits Firefox users an upgrade to 64-bits Firefox if their
system permits. How about we started doing that?

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Xidorn Quan]

On Tue, Feb 2, 2016 at 10:42 AM, Milan Sreckovic  wrote:
>
>> On Feb 1, 2016, at 18:00 , Xidorn Quan  wrote:
>> ...
>>
>> It seems to me if we do, whether enabling SSE2 on x86 doesn't really
>> matter unless we have a good reason. Fewer and fewer people would
>> stick on x86, especially who cares about performance.
>
> Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit 
> Windows.  If I’m reading the data correctly, more than half.  A small 
> percentage of those don’t have SSE2.

It's not surprising to me. We didn't have Firefox release for Win64
until recent, and we haven't ever pushed users with 64bit Windows to
use that version, which we probably should at some point, given the
significant performance improvement.

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Milan Sreckovic]

> On Feb 1, 2016, at 18:00 , Xidorn Quan  wrote:
> ...
> 
> It seems to me if we do, whether enabling SSE2 on x86 doesn't really
> matter unless we have a good reason. Fewer and fewer people would
> stick on x86, especially who cares about performance.

Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit 
Windows.  If I’m reading the data correctly, more than half.  A small 
percentage of those don’t have SSE2.

> 
> If we haven't yet done that, we should. It seems to me the majority
> processors which supports x64 also supports SSE2. If there are really
> some people who use a processor doesn't support SSE2 but are using
> 64bit Firefox, they could simply back to use the 32bit version.
> 
> - Xidorn
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Marco]

SSE2 is always available in 64bit CPUs, it's included in the AMD64 
specification.
So I'd be surprised if compilers didn't automatically use SSE2 for 64bit 
targets.


Another interesting data point is that Windows 8.1 doesn't work without 
SSE2 [1],

but I guess most people that use Windows 8.1 have a 64bit CPU.

[1] http://windows.microsoft.com/en-GB/windows-8/what-is-pae-nx-sse2

- Marco.

Il 01/02/16 15:00, Xidorn Quan ha scritto:

On Tue, Feb 2, 2016 at 7:04 AM, Benjamin Smedberg  wrote:


On 1/29/2016 2:05 PM, Cameron Kaiser wrote:

On 1/29/16 9:43 AM, Ashley Gullen wrote:

FWIW, the Steam Hardware Survey says 99.99% of users have SSE2 (under
"other settings"): http://store.steampowered.com/hwsurvey


For that to be valid, one must assume that the population of Firefox users
and Steam users are sufficiently similar. I don't think that's necessarily
true since most Steam titles have substantially higher system requirements.

The last time we broke this (by accident) was several years ago. At the
time, we got vigorous complaining from various people who had relatively
recent bare-bones machines without SSE2.

It might be worth reconsidering now: I'm not willing to throw away 0.5% of
our users without good cause, but perhaps there is a good cause to be made
here? What would the performance gain be for the remaining 99.5% of users,
realizing that we already have dynamic SSE2/non-SSE switching in place for
some of our hottest paths.

The main question here I think is, whether we've enabled SSE2 for 64bit build

It seems to me if we do, whether enabling SSE2 on x86 doesn't really
matter unless we have a good reason. Fewer and fewer people would
stick on x86, especially who cares about performance.

If we haven't yet done that, we should. It seems to me the majority
processors which supports x64 also supports SSE2. If there are really
some people who use a processor doesn't support SSE2 but are using
64bit Firefox, they could simply back to use the 32bit version.

- Xidorn



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Unsafe CPOWs are about to be outlawed in browser code

[Kris Maglione]

On Tue, Feb 02, 2016 at 01:39:00AM +0300, Dmitry Gutov wrote:

On 02/02/2016 12:29 AM, Kris Maglione wrote:

That falls into the category of "unless it is calling browser code and
making it do something unsafe".


That's too bad. I'm just reusing a querying function from there, and a 
pretty small one.


It's not as small as you might think. In the best case, that 
function makes two CPOW calls, one for getElementsByTagName, and 
one to check its length. If any  tags are returned, it 
makes as many as 5 calls for each one, and a sixth for the first 
one that matches.


In the cases where the content process isn't blocked on sync 
message, any or all of those requests might go out while the 
content process is in the middle of executing a slow script. The 
contents of those elements could change between each call. The 
browser could navigate to a different page.


Yes, that will add some complexity. It seems I can just copy 
getDescriptionFromDocument's definition until I get around to 
supporting E10s properly.


You could, but it would really be better not to. Unsafe CPOW 
usage is called unsafe for a reason.


Should be a plus, but the user's just waiting for the action to 
complete at this point, so it's not like there are many other things 
for the browser process to do.


You might be surprised. In your case, the difference between 
making simultaneous asynchronous requests to look up existing 
bookmarks and to get the description, and making blocking, 
synchronous calls for both, could easily be the difference 
between the action appearing to complete immediately, and it 
taking, at the very least, a noticeable amount of time.


In the mean time, since you're blocking the event loop on the 
requests, it means that the UI is essentially frozen. Animations 
and roll-over effects are stopped. If the content process is in 
the middle of a slow script, and the hard drive is busy, the UI 
could easily be completely unresponsive for seconds at a time.


There are definitely worse times to do synchronous bookmark 
queries and unsafe CPOW requests than in response to a user 
clicking a button, but that doesn't mean they don't cause 
problems.


--
Kris Maglione
Firefox Add-ons Engineer
Mozilla Corporation

If C gives you enough rope to hang yourself, C++ gives you enough rope
to bind and gag your neighbourhood, rig the sails in a small ship and
still have enough rope left to hang yourself from the yardarm.
--Anonymous

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Jeff Muizelaar]

I don't think there are any compilers that support x64 without SSE2.
SSE2 registers are required for passing float parameters in both MS
and System V ABIs.

-Jeff

On Mon, Feb 1, 2016 at 6:00 PM, Xidorn Quan  wrote:
> On Tue, Feb 2, 2016 at 7:04 AM, Benjamin Smedberg  
> wrote:
>>
>>
>> On 1/29/2016 2:05 PM, Cameron Kaiser wrote:
>>>
>>> On 1/29/16 9:43 AM, Ashley Gullen wrote:

 FWIW, the Steam Hardware Survey says 99.99% of users have SSE2 (under
 "other settings"): http://store.steampowered.com/hwsurvey
>>>
>>>
>>> For that to be valid, one must assume that the population of Firefox users
>>> and Steam users are sufficiently similar. I don't think that's necessarily
>>> true since most Steam titles have substantially higher system requirements.
>>
>> The last time we broke this (by accident) was several years ago. At the
>> time, we got vigorous complaining from various people who had relatively
>> recent bare-bones machines without SSE2.
>>
>> It might be worth reconsidering now: I'm not willing to throw away 0.5% of
>> our users without good cause, but perhaps there is a good cause to be made
>> here? What would the performance gain be for the remaining 99.5% of users,
>> realizing that we already have dynamic SSE2/non-SSE switching in place for
>> some of our hottest paths.
>
> The main question here I think is, whether we've enabled SSE2 for 64bit build
>
> It seems to me if we do, whether enabling SSE2 on x86 doesn't really
> matter unless we have a good reason. Fewer and fewer people would
> stick on x86, especially who cares about performance.
>
> If we haven't yet done that, we should. It seems to me the majority
> processors which supports x64 also supports SSE2. If there are really
> some people who use a processor doesn't support SSE2 but are using
> 64bit Firefox, they could simply back to use the 32bit version.
>
> - Xidorn
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Xidorn Quan]

On Tue, Feb 2, 2016 at 7:04 AM, Benjamin Smedberg  wrote:
>
>
> On 1/29/2016 2:05 PM, Cameron Kaiser wrote:
>>
>> On 1/29/16 9:43 AM, Ashley Gullen wrote:
>>>
>>> FWIW, the Steam Hardware Survey says 99.99% of users have SSE2 (under
>>> "other settings"): http://store.steampowered.com/hwsurvey
>>
>>
>> For that to be valid, one must assume that the population of Firefox users
>> and Steam users are sufficiently similar. I don't think that's necessarily
>> true since most Steam titles have substantially higher system requirements.
>
> The last time we broke this (by accident) was several years ago. At the
> time, we got vigorous complaining from various people who had relatively
> recent bare-bones machines without SSE2.
>
> It might be worth reconsidering now: I'm not willing to throw away 0.5% of
> our users without good cause, but perhaps there is a good cause to be made
> here? What would the performance gain be for the remaining 99.5% of users,
> realizing that we already have dynamic SSE2/non-SSE switching in place for
> some of our hottest paths.

The main question here I think is, whether we've enabled SSE2 for 64bit build

It seems to me if we do, whether enabling SSE2 on x86 doesn't really
matter unless we have a good reason. Fewer and fewer people would
stick on x86, especially who cares about performance.

If we haven't yet done that, we should. It seems to me the majority
processors which supports x64 also supports SSE2. If there are really
some people who use a processor doesn't support SSE2 but are using
64bit Firefox, they could simply back to use the 32bit version.

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use of C++11 std::unique_ptr for the WOFF2 module

[Nathan Froyd]

On Mon, Feb 1, 2016 at 4:29 AM, Frédéric Wang  wrote:

> I tried updating the source code of WOFF2 to the latest upstream
> version. Unfortunately, try server builds fail on OSX and mobile devices
> because the C++11 class std::unique_ptr does not seem to be available.
> IIUC some bugzilla entries and older threads on this mailing list, at
> the moment only some of the C++11 features are usable in the mozilla
> build system. Does any of the build engineer know whether
> std::unique_ptr can be made easily available? Or should we just patch
> the WOFF2 library to use of std::vector (as was done in earlier version)


We're working on moving all of our platforms to use a C++11-ish standard
library.  For std::unique_ptr, at least, the best tack is to write a small
polyfill based on mfbt/UniquePtr.h.  (It's not clear to me how your
suggestion with std::vector applies here.)  If our UniquePtr isn't a
drop-in replacement for std::unique_ptr, that's worthy of a bug report.

-Nathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Touch events enabled on Windows desktop (nightly only)

[Bill McCloskey]

On Mon, Feb 1, 2016 at 2:12 PM, Gijs Kruitbosch 
wrote:

> Several people including me have been bitten by this, but based on the
> last comment on https://bugzilla.mozilla.org/show_bug.cgi?id=1166564, it
> seems the current plan is "fix a11y to work on e10s so we can enable it for
> a11y users, too" (because it is too difficult to distinguish the UIA touch
> a11y that win8/win10 use from the other ones, apparently).
>
> I too would hope we will fix a11y+e10s, or at least fix the messaging
> about this, before we release.


Fixing a11y+e10s is pretty difficult. It will be many months of work. I
think it makes sense to roll e10s out to most users before a11y support is
ready.

We definitely should investigate making special accommodations for users of
touch devices. But even that is fairly difficult. We have to figure out
what subset of the a11y API is actually being used on these devices and
then make sure that that subset works. As far as I know, finding that
subset is only possibly by experimentation, and it has to be done by
someone with a device where the problem reproduces. And finding people to
work on Windows is not easy.

I don't know what we would do about messaging. We're not planning on having
any UI besides about:support where people will know that e10s is enabled.
The hope is that it will be completely transparent.

I can imagine it's frustrating if you have one of these devices, but we
have to prioritize how we spend our time. And I don't think it's worth
holding up the whole project for a few percent of users, even if they are
the cool ones :-).

-Bill


>
>
> ~ Gijs
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Touch events enabled on Windows desktop (nightly only)

[Gijs Kruitbosch]

On 01/02/2016 21:46, Justin Dolske wrote:

On 2/1/16 9:51 AM, Kartikaya Gupta wrote:

Oh, I should also mention that currently many (if not all) Windows
touchscreen devices have e10s disabled by default, because a
touchscreen seems to trigger the accessibility code which disables
e10s. And if e10s is disabled, APZ is disabled, which means no APZ
touch scrolling.


I assume there's a bug(s) on file for making e10s/a11y work right on
touch devices?

Looking at the TOUCH_ENABLED_DEVICE telemetry probe, while touch devices
are a fairly small segment of the overall userbase (~2%, for beta 44),
it's significantly higher on what I'd expect to be modern hardware (7.4%
of Windows 10 users, 6.9% for Win8.1).


Several people including me have been bitten by this, but based on the 
last comment on https://bugzilla.mozilla.org/show_bug.cgi?id=1166564, it 
seems the current plan is "fix a11y to work on e10s so we can enable it 
for a11y users, too" (because it is too difficult to distinguish the UIA 
touch a11y that win8/win10 use from the other ones, apparently).


I too would hope we will fix a11y+e10s, or at least fix the messaging 
about this, before we release.


~ Gijs

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Touch events enabled on Windows desktop (nightly only)

[Justin Dolske]

On 2/1/16 9:51 AM, Kartikaya Gupta wrote:

Oh, I should also mention that currently many (if not all) Windows
touchscreen devices have e10s disabled by default, because a
touchscreen seems to trigger the accessibility code which disables
e10s. And if e10s is disabled, APZ is disabled, which means no APZ
touch scrolling.


I assume there's a bug(s) on file for making e10s/a11y work right on 
touch devices?


Looking at the TOUCH_ENABLED_DEVICE telemetry probe, while touch devices 
are a fairly small segment of the overall userbase (~2%, for beta 44), 
it's significantly higher on what I'd expect to be modern hardware (7.4% 
of Windows 10 users, 6.9% for Win8.1).


Justin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Unsafe CPOWs are about to be outlawed in browser code

[Kris Maglione]

On Thu, Jan 28, 2016 at 06:30:03PM -0800, raa...@gmail.com wrote:

Hi!

My addon is reportedly broken in the Nightly: 
https://github.com/dgutov/bmreplace/issues/32#issuecomment-176126946


It imports PlacesUIUtils.jsm and calls three functions from it, 
most notably PlacesUIUtils.getDescriptionFromDocument.


How do I "fix" that in the addon, aside for doing the big 
transition to an E10s-friendly architecture?


That falls into the category of "unless it is calling browser 
code and making it do something unsafe".


If you need to use that function from the main process, you can 
only do so from the message listener for a synchronous message 
from the content process (or a few other similar situations).


While you're at it, though, it would be a good idea to make that 
function asynchronous, so that you can check the description 
from the content process, and look up whether the URL is 
bookmarked, without blocking the browser process.


--
Kris Maglione
Firefox Add-ons Engineer
Mozilla Corporation

It is well to know something of the manners of various peoples, in
order more sanely to judge our own, and that we do not think that
everything against our modes is ridiculous, and against reason, as
those who have seen nothing are accustomed to think.
--Rene Descartes

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Benjamin Smedberg]

On 1/29/2016 2:05 PM, Cameron Kaiser wrote:

On 1/29/16 9:43 AM, Ashley Gullen wrote:

FWIW, the Steam Hardware Survey says 99.99% of users have SSE2 (under
"other settings"): http://store.steampowered.com/hwsurvey


For that to be valid, one must assume that the population of Firefox 
users and Steam users are sufficiently similar. I don't think that's 
necessarily true since most Steam titles have substantially higher 
system requirements.


The last time we broke this (by accident) was several years ago. At the 
time, we got vigorous complaining from various people who had relatively 
recent bare-bones machines without SSE2.


It might be worth reconsidering now: I'm not willing to throw away 0.5% 
of our users without good cause, but perhaps there is a good cause to be 
made here? What would the performance gain be for the remaining 99.5% of 
users, realizing that we already have dynamic SSE2/non-SSE switching in 
place for some of our hottest paths.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Milan Sreckovic]

Telemetry reports 99.77% with SSE2…

http://people.mozilla.org/~danderson/moz-gfx-telemetry/www/#view=system 


—
- Milan



> On Jan 29, 2016, at 15:33 , Kartikaya Gupta  wrote:
> 
> I also want to highlight the thing at the end of the gist linked above
> - the majority of the non-SSE2 population are on 43.0.4. That is,
> they're keeping up-to-date, and would likely be affected by this more
> than somebody stranded on an old version.
> 
> On Fri, Jan 29, 2016 at 3:29 PM, Chris H-C  wrote:
>> tl;dr - Around 99.5% of Firefox Desktop clients on release channel
>> represented by (a 20% sample of) pings submitted by on January 21, 2016 had
>> "hasSSE2" detected.
>> 
>> Here's the analysis and results on github. Please feel free to check my
>> work: https://gist.github.com/chutten/4959c873d7fbbec0785a
>> 
>> Keep in mind we cannot prove a negative from this. I cannot state that
>> those pings without hasSSE2 correspond to clients that don't have SSE2
>> support on their machines. So I tried (and failed, see bottom section of
>> that gist) to keep analysis and discussion centred on the "hasSSE"
>> population alone.
>> 
>> :chutten
>> 
>> On Fri, Jan 29, 2016 at 2:44 PM, Mike Hoye  wrote:
>> 
>>> On 2016-01-29 2:05 PM, Cameron Kaiser wrote:
>>> 
 On 1/29/16 9:43 AM, Ashley Gullen wrote:
 
> FWIW, the Steam Hardware Survey says 99.99% of users have SSE2 (under
> "other settings"): http://store.steampowered.com/hwsurvey
> 
 
 For that to be valid, one must assume that the population of Firefox
 users and Steam users are sufficiently similar. I don't think that's
 necessarily true since most Steam titles have substantially higher system
 requirements.
 
>>> While that's a fair point, Microsoft turned compiling with SSE2 on by
>>> default in Visual Studio in 2012, and it's been basically impossible to buy
>>> an x86 CPU without it since...  2004 or so?
>>> 
>>> I've tapped chutten about this, and he says:
>>> 
>>> 14:33 < chutten> Easy as pie. ping["environment/system/cpu/extensions"]
>>> contains "SSE2"
>>> 14:33 < chutten> or, rather, the inverse
>>> 
>>> ... which he then explained to me means "we can get our own data in short
>>> order."
>>> 
>>> He says it'll be straightforward to pull in, so he's going to do that.
>>> 
>>> 
>>> - mhoye
>>> 
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>> 
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Touch events enabled on Windows desktop (nightly only)

[Kartikaya Gupta]

Oh, I should also mention that currently many (if not all) Windows
touchscreen devices have e10s disabled by default, because a
touchscreen seems to trigger the accessibility code which disables
e10s. And if e10s is disabled, APZ is disabled, which means no APZ
touch scrolling. If you encounter bugs in this configuration, again,
please file. If you want to force-enable e10s (and therefore APZ), you
can set the browser.tabs.remote.force-enable pref to true.

On Mon, Feb 1, 2016 at 12:46 PM, Kartikaya Gupta  wrote:
> In bug 1180706 I turned on the dom.w3c_touch_events.enabled pref for
> Windows desktop builds. This should be in Jan 31 nightly. For devices
> that have touchscreens, this has two effects:
>
> 1) Touch scrolling now uses APZ. The physics will probably need some
> tuning, but if you see correctness issues with scrolling, tapping,
> long-tapping, etc., please file a bug and cc me. Pinch zooming is
> currently disabled.
>
> 2) Web content will be receiving touch events. This may result in
> pages responding very differently when using touch to interact with
> it. Pages may also do different things on load, because they can
> detect the presence of touch interfaces via window.Touch and
> window.TouchEvent which wasn't the case before. If you observe
> strange/buggy behaviour on touchscreen windows devices that wasn't
> there before, try setting dom.w3c_touch_events.enabled to false
> (restart required) to confirm it was caused by this change, and please
> file a bug and cc me if so.
>
> For the moment this change will remain on Nightly until we are
> confident that it doesn't break anything major.
>
> Note also that touch event support has been enabled on Linux for a
> while now (not just Nightly) although you need MOZ_USE_XINPUT2=1 in
> the environment for it to work. If you have a Linux touchscreen device
> please feel free to try it out there as well and file bugs if you
> encounter any problems.
>
> Thanks!
> kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Touch events enabled on Windows desktop (nightly only)

[Kartikaya Gupta]

In bug 1180706 I turned on the dom.w3c_touch_events.enabled pref for
Windows desktop builds. This should be in Jan 31 nightly. For devices
that have touchscreens, this has two effects:

1) Touch scrolling now uses APZ. The physics will probably need some
tuning, but if you see correctness issues with scrolling, tapping,
long-tapping, etc., please file a bug and cc me. Pinch zooming is
currently disabled.

2) Web content will be receiving touch events. This may result in
pages responding very differently when using touch to interact with
it. Pages may also do different things on load, because they can
detect the presence of touch interfaces via window.Touch and
window.TouchEvent which wasn't the case before. If you observe
strange/buggy behaviour on touchscreen windows devices that wasn't
there before, try setting dom.w3c_touch_events.enabled to false
(restart required) to confirm it was caused by this change, and please
file a bug and cc me if so.

For the moment this change will remain on Nightly until we are
confident that it doesn't break anything major.

Note also that touch event support has been enabled on Linux for a
while now (not just Nightly) although you need MOZ_USE_XINPUT2=1 in
the environment for it to work. If you have a Linux touchscreen device
please feel free to try it out there as well and file bugs if you
encounter any problems.

Thanks!
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Bug Program Next Steps

[smaug]

On 01/31/2016 08:35 PM, Axel Hecht wrote:

I'm also generally concerned how UX bugs or crashes would fit into these 
buckets. UX bugs, and possibly any other flavor of ideation, have the
majority of work associated with "should we do this or not". And crashes as a 
single crash stack are hardly ever actionable.



I could disagree with this. Crashes with a single crash stack can be very 
actionable. In those cases when crash-stat gives a proper stack trace, it is
often (not at all always though) easy to see why the crash happens.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Bug Program Next Steps

[Dave Townsend]

On Fri, Jan 29, 2016 at 3:45 PM, Emma Humphries  wrote:
> Bug Program Next Steps
>
> Over the last week, I’ve asked you to step up and identify developers who
> will be responsible for bugs triaged into their component (in Firefox, Core,
> Toolkit, Fennec iOS, and Fennec Android.)
>
> Why This Matters
>
> Bugs are a unit of quality we can use to see how we’re doing.
>
>
> We believe that the number of outstanding, actionable bugs is the best
> metric of code quality available, and that how this number changes over time
> will be a strong indicator of the evolving quality of Firefox. Actionable
> bugs are those with the status NEW for which the next action required - if
> any - is unambiguous: does the bug need immediate attention, will it be
> worked on for a future release, will it be worked on at all?
>
>
> There are two parts to maintaining the value of that metric. First, we want
> to make better assertions about the quality of our releases by making clear
> decisions about which bugs must be fixed for each release (urgent) and
> actively tracking those bugs. The other is the number of good bugs filed by
> our community. Filing a bug report is a gateway to greater participation in
> the Mozilla project, and we owe it to our community to make quick and clear
> decisions about each bug.
>
>
> Making decisions on new bugs quickly helps us avoid point releases, and
> gives positive feedback to people filing bugs so that they will file more
> good bugs.
>
> What’s Your Role
>
> Starting in the second quarter of this year, if you’ve taken on a component,
> I’m expecting you or your team to look at the bugs which landed in the
> component on a more frequent basis than a weekly triage.

I'm concerned about making this sort of demand when the component
owner is not an employee, or is the expectation that only employees
would be in these roles?

> In February, we’re starting a pilot with four groups of components where
> we’ll get the process changes and field tested, so that we can we can take
> the changes to all the affected bugzilla components for review and comment
> before we implement them across all of the work on Firefox.
>
> Hold on, we already have a weekly triage!
>
> That’s fantastic, but a weekly pace means we miss bugs that affect upcoming
> releases. So I’m expecting you to scan that list of inbound bugs daily for
> the urgent ones (I’ll define urgent below) and put them into one of the
> states described in the next section, the others can go into your regular
> triage.
>
> At Your Regular Triage
>
> You’ll look at the bugs which landed in your component and decide on how to
> act on them using the states described in the next section.
>
> We don’t have a regular triage
>
> This is a process which you’ll need to start, and the bug program team will
> help with this.
>
> This is potentially a lot of work for one person
>
> Looking at the urgent bugs does not have to be one person’s task. You can
> have a rotation of people doing this. Look at the Core::Graphics triage wiki
> for an example of what you could be doing.
>
> Bug States
>
> Initially, these states will be marked in bugzilla.mozilla.org using
> whiteboard tags during the pilot. The bugzilla team will be making further
> changes once we’ve settled on a process.
>
>
> You’ll be looking at bugs in your component as they land, in your component.
> We expect most of these will be NEW bugs, but some will be in UNCONFIRMED.
>
>
> There are four states you’ll need to decide to put each bug, and in your
> reviews between your team’s weekly triages, we want you to be on the watch
> for bugs with characteristics which make getting it in front of someone
> urgent: these are bugs with crash, topcrash, regression, or dataloss
> keywords; crash logs linked in comments; references to mozregression
> results; and others.
>
>
> The bug should not remain in this state after your review of it.
>
>
> You’ll need to decide which of the following states you’ll move this bug
> into, if you can’t you’ll need to be taking action: such as getting someone
> to run mozregression, need info’ing a domain expert, looking at checkins,
> and whatever else techniques you have to get a bug reduced.
>
>
> Once you have an understanding of the bug, you should assign it to one of
> these states.
>
> Urgent
>
> Assigned to a developer, release tracking flags nominated, and set at
> priority `P1`. If the bug is being worked on by somebody from outside your
> core team, a team mentor should be assigned.
>
>
> All these need to be set for the bug when you assign it to this state. This
> state is for bugs you find in your daily review which need a developer
> immediately.
>
>
> If the bug is not in need of immediate attention, then your team’s process
> should land the bug in one of the following states.
>
> Backlog
>
> This is a NEW bug that the team acknowledges is a bug, but is not a current
> priority, but will consider taking on. If the bug contains regression,
> crash, top

Re: Use of C++11 std::unique_ptr for the WOFF2 module

[Frédéric Wang]

Le 01/02/2016 16:23, Ehsan Akhgari a écrit :
> 
> Also the lack of libc++ on OSX makes this an issue there, which should
> explain the OSX issue mentioned above.
> 

Yes, I tried to follow what's done in build/clang-plugin/moz.build
This allowed to compile the c++ files but linking failed.

-- 
Frédéric Wang
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use of C++11 std::unique_ptr for the WOFF2 module

[Jeff Muizelaar]

Lee Salzman came up with a hacky solution to this problem for the Skia
update that he's working on. I haven't seen it yet, but apparently it
builds.

-Jeff

On Mon, Feb 1, 2016 at 4:29 AM, Frédéric Wang  wrote:
> Dear all,
>
> I'm trying to upgrade our local copy of OTS to version 5.0.0 [1]. OTS
> relies on the Brotli and WOFF2 libraries, whose source code we currently
> include in mozilla-cental.
>
> I tried updating the source code of WOFF2 to the latest upstream
> version. Unfortunately, try server builds fail on OSX and mobile devices
> because the C++11 class std::unique_ptr does not seem to be available.
> IIUC some bugzilla entries and older threads on this mailing list, at
> the moment only some of the C++11 features are usable in the mozilla
> build system. Does any of the build engineer know whether
> std::unique_ptr can be made easily available? Or should we just patch
> the WOFF2 library to use of std::vector (as was done in earlier version)?
>
> Thanks,
>
> --
> Frédéric Wang
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1227058
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Please stop revving UUIDs when changing XPIDL interface

[Ehsan Akhgari]

On Mon, Feb 1, 2016 at 12:42 AM, Gregory Szorc  wrote:

> On Fri, Jan 29, 2016 at 1:52 PM, Ehsan Akhgari 
> wrote:
>
>> (Sending this in another thread in case people didn't see my note at the
>> end of the original thread.)
>>
>> The new rules are in effect for mozilla-central and the repositories that
>> merge into it.  Revving UUIDs is no longer necessary.
>>
>
> Is `mach update-uuids` still necessary? If not, can we get a bug on file
> to remove it?
>

No, filed bug 1244736 to remove it.

-- 
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use of C++11 std::unique_ptr for the WOFF2 module

[Ehsan Akhgari]

On 2016-02-01 9:33 AM, Ted Mielczarek wrote:

On Mon, Feb 1, 2016, at 04:29 AM, Frédéric Wang wrote:

Dear all,

I'm trying to upgrade our local copy of OTS to version 5.0.0 [1]. OTS
relies on the Brotli and WOFF2 libraries, whose source code we currently
include in mozilla-cental.

I tried updating the source code of WOFF2 to the latest upstream
version. Unfortunately, try server builds fail on OSX and mobile devices
because the C++11 class std::unique_ptr does not seem to be available.
IIUC some bugzilla entries and older threads on this mailing list, at
the moment only some of the C++11 features are usable in the mozilla
build system. Does any of the build engineer know whether
std::unique_ptr can be made easily available? Or should we just patch
the WOFF2 library to use of std::vector (as was done in earlier version)?


The biggest hurdle for us using C++11 features historically has been
stlport on Android/B2G. Nathan Froyd has investigated fixing this in the
past, but I don't know what the current status is.


Also the lack of libc++ on OSX makes this an issue there, which should 
explain the OSX issue mentioned above.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Flexbox + img aspect ratio

[Amit Zur]

Thank you Daniel

On Saturday, January 30, 2016 at 12:50:55 AM UTC+2, Daniel Holbert wrote:
> I believe this is a version of
>  https://bugzilla.mozilla.org/show_bug.cgi?id=1030952
> 
> The underlying issue is described here:
>  https://bugzilla.mozilla.org/show_bug.cgi?id=1030952#c2
> 
> I believe the tentative patch there works, but it's not sufficient to
> entirely fix the bug, as discussed in
>  https://bugzilla.mozilla.org/show_bug.cgi?id=1030952#c9
> 
> Possible workaround for the moment: wrap your  in a wrapper-block
> with 'min-width:0', and force the img (now a child of a block) to be
> "display:block" itself as well:
>  https://jsfiddle.net/dfpj6fag/7/
> 
> ~Daniel
> 
> On 01/28/2016 04:52 AM, Amit Zur wrote:
> > I'm seeing an aberration in behaviour of img as a flex-item.
> > Not sure what is the reason, but the img doesn't preserve aspect ratio, as 
> > seen in this fiddle:
> > https://jsfiddle.net/dfpj6fag/6/
> > 
> > I saw this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=972595 but I 
> > can't understand if it's related or what is the exact reason the ratio is 
> > not maintained.
> > 
> > Thanks,
> > Amit
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Unsafe CPOWs are about to be outlawed in browser code

[raaahh]

четверг, 28 января 2016 г., 19:57:59 UTC+3 пользователь Dave Townsend написал:
> I don't think that this is meant to impact add-on code at all, unless
> it is calling browser code and making it do something unsafe, in which
> case it would be up to the add-on developer to fix that. It's probably
> worth filing a bug to track what is going on there though.

Hi!

My addon is reportedly broken in the Nightly: 
https://github.com/dgutov/bmreplace/issues/32#issuecomment-176126946

It imports PlacesUIUtils.jsm and calls three functions from it, most notably 
PlacesUIUtils.getDescriptionFromDocument.

How do I "fix" that in the addon, aside for doing the big transition to an 
E10s-friendly architecture?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Use of C++11 std::unique_ptr for the WOFF2 module

[Ted Mielczarek]

On Mon, Feb 1, 2016, at 04:29 AM, Frédéric Wang wrote:
> Dear all,
> 
> I'm trying to upgrade our local copy of OTS to version 5.0.0 [1]. OTS
> relies on the Brotli and WOFF2 libraries, whose source code we currently
> include in mozilla-cental.
> 
> I tried updating the source code of WOFF2 to the latest upstream
> version. Unfortunately, try server builds fail on OSX and mobile devices
> because the C++11 class std::unique_ptr does not seem to be available.
> IIUC some bugzilla entries and older threads on this mailing list, at
> the moment only some of the C++11 features are usable in the mozilla
> build system. Does any of the build engineer know whether
> std::unique_ptr can be made easily available? Or should we just patch
> the WOFF2 library to use of std::vector (as was done in earlier version)?

The biggest hurdle for us using C++11 features historically has been
stlport on Android/B2G. Nathan Froyd has investigated fixing this in the
past, but I don't know what the current status is.

-Ted

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to remove #ifdef XP_MACOSX in xul files?

[Philipp Kewisch]

You can use runtime checks for the OS, e.g. using Services.appinfo

Philipp

On 2/1/16 11:09 AM, 罗勇刚(Yonggang Luo)  wrote:
> I means there is any instruction in XUL
> to remove the #ifdef XP_MACOSX
> but still preserve the semantics.
> 
> On Mon, Feb 1, 2016 at 2:55 PM, Martin Thomson  wrote:
> 
>> sed -i~ -e '/#ifdef XP_MACOSX/d' xul files
>>
>> I think that we need more information on what it is that you intend to
>> do if we are to make a sensible suggestion.
>>
>> On Mon, Feb 1, 2016 at 5:23 PM, Yonggang Luo 
>> wrote:
>>> How to remove #ifdef XP_MACOSX in xul files?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to remove #ifdef XP_MACOSX in xul files?

[Yonggang Luo]

I means there is any instruction in XUL
to remove the #ifdef XP_MACOSX
but still preserve the semantics.

On Mon, Feb 1, 2016 at 2:55 PM, Martin Thomson  wrote:

> sed -i~ -e '/#ifdef XP_MACOSX/d' xul files
>
> I think that we need more information on what it is that you intend to
> do if we are to make a sensible suggestion.
>
> On Mon, Feb 1, 2016 at 5:23 PM, Yonggang Luo 
> wrote:
> > How to remove #ifdef XP_MACOSX in xul files?
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>



-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Use of C++11 std::unique_ptr for the WOFF2 module

[Frédéric Wang]

Dear all,

I'm trying to upgrade our local copy of OTS to version 5.0.0 [1]. OTS
relies on the Brotli and WOFF2 libraries, whose source code we currently
include in mozilla-cental.

I tried updating the source code of WOFF2 to the latest upstream
version. Unfortunately, try server builds fail on OSX and mobile devices
because the C++11 class std::unique_ptr does not seem to be available.
IIUC some bugzilla entries and older threads on this mailing list, at
the moment only some of the C++11 features are usable in the mozilla
build system. Does any of the build engineer know whether
std::unique_ptr can be made easily available? Or should we just patch
the WOFF2 library to use of std::vector (as was done in earlier version)?

Thanks,

-- 
Frédéric Wang

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1227058
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Firefox Desktop] Issues found: January 25th to January 29th

[Andrei Vaida]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Manual QA 
team last week,*January 25th - January 29th* (week 4).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1242891 
AsyncShutdown crash in Media shutdown: blocking on media thread
Core
Audio/Video
YES NOBODY


*BETA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1243712 
crash in XUL@0x17555ec | _dispatch_client_callout
Core
Web Speech
NO  NOBODY
1243753 
	Hand tool not displayed while hovering over Sign in to Sync from Sync 
tabs panel

Firefox
Sync
NO  NOBODY


*AURORA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1243309 
	crash in nsTArray_Impl::RemoveElementsAt | 
mozilla::dom::DeferredFinalizerImpl::DeferredFinalize

Core
Plug-ins
NO  NOBODY
1243310 
Cert error page 'advanced' section is misaligned
Firefox
General
YES Panos Astithas
1243353 
	Make the "Report errors like this" option keyboard accessible on the 
cert error page

Firefox
Keyboard Navigation
NO  NOBODY
1243385 
Bad repainting while scrolling on gaming.youtube.com
Core
Panning and Zooming
YES NOBODY


*NIGHTLY CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1242343 
crash in msmpeg2vdec.dll@0x25a487
Core
Audio/Video: Playback
NO  NOBODY


*ESR CHANNEL*
none

Regards,
Andrei.
Andrei Vaida| QC Team Lead

SOFTVISION | 57 Republicii Street, 400489 Cluj-Napoca, Romania
Email: andrei.va...@softvision.ro  | 
Web: www.softvision.ro 


The content of this communication is classified as SOFTVISION 
Confidential and Proprietary Information.



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform