Intent to implement and ship: CSS and SVG filters for canvas 2D

[Markus Stange]

Summary: The "filter" property on CanvasRenderingContext2D allows 
authors to specify a filter that will get applied during canvas drawing. 
It accepts the same values as the CSS "filter" property, so CSS filter 
shorthand functions, references to SVG filters, and chained combinations 
of the two.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=927892 and 
https://bugzilla.mozilla.org/show_bug.cgi?id=1173545


Link to standard: This would be added to the canvas spec. There has been 
some discussion [1] of this feature on the WhatWG mailing list, but no 
actual spec has been written yet.


Platform coverage: All

Estimated or target release: Firefox 41 or 42

Preference behind which this will be implemented:
This feature has been implemented behind the preference 
canvas.filters.enabled . We are planning to flip this preference to true 
by default in the very near future. The pref flip is being tracked in 
bug 1173545.


[1] 
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/0110.html

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

Re: Intent to implement and ship: CSS and SVG filters for canvas 2D

[Jet Villegas]

!!! \o/ !!!

We'll also post the proposed spec on this wiki page:
https://wiki.mozilla.org/CanvasFilters

--Jet


On Mon, Jun 15, 2015 at 10:15 AM, Markus Stange 
wrote:

> Summary: The "filter" property on CanvasRenderingContext2D allows authors
> to specify a filter that will get applied during canvas drawing. It accepts
> the same values as the CSS "filter" property, so CSS filter shorthand
> functions, references to SVG filters, and chained combinations of the two.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=927892 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=1173545
>
> Link to standard: This would be added to the canvas spec. There has been
> some discussion [1] of this feature on the WhatWG mailing list, but no
> actual spec has been written yet.
>
> Platform coverage: All
>
> Estimated or target release: Firefox 41 or 42
>
> Preference behind which this will be implemented:
> This feature has been implemented behind the preference
> canvas.filters.enabled . We are planning to flip this preference to true by
> default in the very near future. The pref flip is being tracked in bug
> 1173545.
>
> [1]
> https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/0110.html
> ___
> 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: Intent to implement and ship: CSS and SVG filters for canvas 2D

[Rik Cabanier]

Great news! I'm super excited to see this go in!

On Mon, Jun 15, 2015 at 10:15 AM, Markus Stange 
wrote:

> Summary: The "filter" property on CanvasRenderingContext2D allows authors
> to specify a filter that will get applied during canvas drawing. It accepts
> the same values as the CSS "filter" property, so CSS filter shorthand
> functions, references to SVG filters, and chained combinations of the two.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=927892 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=1173545
>
> Link to standard: This would be added to the canvas spec. There has been
> some discussion [1] of this feature on the WhatWG mailing list, but no
> actual spec has been written yet.
>
> Platform coverage: All
>
> Estimated or target release: Firefox 41 or 42
>
> Preference behind which this will be implemented:
> This feature has been implemented behind the preference
> canvas.filters.enabled . We are planning to flip this preference to true by
> default in the very near future. The pref flip is being tracked in bug
> 1173545.
>
> [1]
> https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/0110.html
> ___
> 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

[Firefox Desktop] Issues found: June 8th to June 12th

[Florin Mezei]

Hi everyone,

 

You can find below the list of new issues found and filed by the Desktop
Manual QA team last week (Week 24: June 08 - June 12). 

 

Additional details on the team's priorities last week, as well as the plans
for the current week can be found at:
https://etherpad.mozilla.org/DesktopManualQAWeeklyStatus.

Release Channel:
No bugs.

 

Beta Channel:

NEW Bug   1173359 -
History items are duplicated after reenabling history sync

*   Regression: -
*   Severity: Normal.

NEW Bug   1174151 -
Large OOM in mozilla::WebGLTexture::EnsureNoUninitializedImageData

*   Regression: No.
*   Severity: Critical.

 

Aurora Channel:
NEW Bug   1172407 -
[Linux] Clicking the Performance settings button checks the first option and
dismisses the menu

*   Regression: Yes - since 2015-03-16
*   Severity: Normal.

NEW Bug   1172408 -
Clicking anywhere on the sidebar displayed for a label results in an error
thrown by marker-details.js

*   Regression: Yes - since 2015-03-24
*   Severity: Normal.

NEW Bug   1172412 -
[Linux] The Filters menu places the checkbox behind the markers

*   Regression: Yes - since 2014-03-16
*   Severity: Normal.

NEW Bug   1172847 -
'Let's Talk About' hard to see in conversation window after someone joins
the conversation due to its color

*   Regression: No.
*   Severity: Normal.

ASSI Bug   1173695 -
Unable to import specific profiles which cause an error to be thrown by
recording-utils.js:303:6

*   Regression: No.
*   Severity: Normal.

NEW Bug   1173775 -
Right-clicking a filename from the Call Tree opens its source in a new
window

*   Regression: No.
*   Severity: Normal.

 

Nightly Channel:
NEW Bug   1172835 -
The warning triangle misses from "Some extensions could not be verified"
button

*   Regression: No.
*   Severity: Normal.

NEW Bug   1172910 -
Context is activated even though 'Let`s talk about' is not ticked from
conversation window

*   Regression: No.
*   Severity: Normal.

NEW Bug   1172915 -
Extra space between checkbox and name of some websites in conversation
window edit context

*   Regression: No.
*   Severity: Normal.

NEW Bug   1173355 -
[RTL] Context positioned wrong in standalone UI

*   Regression: No.
*   Severity: Normal.

NEW Bug   1174080 -
Missing tick mark in toolbar's dropdown

*   Regression: Yes - since 2015-06-05
*   Severity: Normal.

NEW Bug   1174132 -
Incomplete name shown in context if website name contains vertical bar

*   Regression: No.
*   Severity: Normal.

 

ESR Channel:
No bugs.

 

Regards,

Florin.

 

Florin Mezei | QC Team Lead

SOFTVISION | 57 Republicii Street, 400489 Cluj-Napoca, Romania
Email:   fme...@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

Intent to implement: CSS Containment

[Kyle Zentner]

This proposed feature would allow authors to annotate when an element and
its descendants will not (or should not) affect the rest of the page. The
primary intended benefit of such annotations is to allow browsers various
layout and rendering optimizations.

As currently described , this
feature adds a css property 'contain' with four potential values 'layout',
'style', and 'paint' as well as 'strict', which is equivalent to the
previous three. Details are still being worked out, as can be seen from the
mailing list.


This feature is tracked by Bug 1150081.


Most likely, this will be implemented in FF42, gated behind
"layout.css.contain.enabled". The timeline for performing the possible
optimizations will probably be a fair bit longer.

As far as I can tell, no other browsers are actively working on this,
although patches for 'contain: strict' were posted to blink-dev

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

Re: Intent to implement and ship: CSS and SVG filters for canvas 2D

[Xidorn Quan]

On Tue, Jun 16, 2015 at 3:15 AM, Markus Stange  wrote:

> Summary: The "filter" property on CanvasRenderingContext2D allows authors
> to specify a filter that will get applied during canvas drawing. It accepts
> the same values as the CSS "filter" property, so CSS filter shorthand
> functions, references to SVG filters, and chained combinations of the two.
>

Is there any signal from other browser vendors? It seems to me that only
Adobe and us took part in this discussion.

I tend to vote against shipping this feature at present, as far as no spec
is written, and no other browser vendors agree with it yet. I think it
violates our guidelines. [1]

[1]
https://wiki.mozilla.org/WebAPI/ExposureGuidelines#When_is_an_API_ready_to_be_shipped_by_Gecko.3F

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

Intent to implement and ship: Unprivilaged WEBGL_debug_renderer_info

[Jeff Gilbert]

Summary:
The WEBGL_debug_renderer_info extension allows for querying which driver
(and commonly GPU) a WebGL context is running on. Specifically, it allows
querying the RENDERER and VENDOR strings of the underlying OpenGL driver.

By default, RENDERER and VENDOR queries in WebGL yield safe but useless
values. (For example, Gecko returns "Mozilla"/"Mozilla" for
RENDERER/VENDOR) Queries to UNMASKED_RENDERER_WEBGL and
UNMASKED_VENDOR_WEBGL yield the RENDERER and VENDOR string of the
underlying graphics driver. These values are combined to form the "WebGL
Renderer" field in about:support. On my system, these are:
* UNMASKED_RENDERER_WEBGL: "ANGLE (NVIDIA GeForce GT 750M Direct3D11 vs_5_0
ps_5_0)"
* UNMASKED_VENDOR_WEBGL: "Google Inc." [1]

Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1171228

Link To Standard:
https://www.khronos.org/registry/webgl/extensions/WEBGL_debug_renderer_info/

Do other browser engines implement this:
Chrome and IE implement this; Safari does not.

Platform Coverage: All platforms.

Current Target Release: Firefox 41

Related Preferences:
* "webgl.disable-debug-renderer-info" (default: false): Disable this
extension for unprivileged content.
* "webgl.renderer-string-override" (default: ""): Overrides
UNMASKED_RENDERER_WEBGL query result when non-empty.
* "webgl.vendor-string-override" (default: ""): Overrides
UNMASKED_VENDOR_WEBGL query result when non-empty.

Security and Privacy Concerns:
* Traditional user-agent sniffing concerns. (Known antipattern)
* This info includes what GPU is being used, which may contribute to
marketing profiles.
* This info adds easily-accessible bits of entropy that improve
fingerprinting, reducing privacy. (Panopticlick and others have
demonstrated that this is already very effective)

Web Developer Use-Cases:
* Sites can more easily and immediately identify and address concerns
caused by specific hardware or drivers. Currently, apps must
unconditionally workaround an issue until we can ship a fix via browser
updates.This can mean performance degradation for unaffected machines for,
sometimes for weeks.
* Sites can collate and cross-reference drivers and hardware when tracking
issues both user-reported and auto-detected, which both helps sites
identify problematic hardware, and helps browsers fix these issues in turn.
* This allows sites to offer better estimates of performance, and offer
reasonable defaults for quality settings.

[1] On Windows, we use ANGLE as an intermediary driver on top of D3D, hence
the VENDOR string being "Google, Inc." and not "NVIDIA" here.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: CSS and SVG filters for canvas 2D

[Jet Villegas]

Markus, Tobias, and Tantek will update the wiki page with our proposed
normative text.

Our key use case here is Shumway, where graphics filter implementations in
JS code have not (yet) been able to offer acceptable performance
characteristics in Canvas2D. We've proven that it's polyfillable in other
browsers, though with the performance characteristics already mentioned.
Because of the Shumway dependency, we'll ship it even if we have to call it
mozCanvasFilters or hide it behind a Shumway pref--do you have a preference
on this?

I'd rather not hide the feature as I believe it's useful for the Web at
large, especially for applications currently using the Flash Player for
filter effects.

--Jet

On Mon, Jun 15, 2015 at 4:05 PM, Xidorn Quan  wrote:

> On Tue, Jun 16, 2015 at 3:15 AM, Markus Stange 
> wrote:
>
> > Summary: The "filter" property on CanvasRenderingContext2D allows authors
> > to specify a filter that will get applied during canvas drawing. It
> accepts
> > the same values as the CSS "filter" property, so CSS filter shorthand
> > functions, references to SVG filters, and chained combinations of the
> two.
> >
>
> Is there any signal from other browser vendors? It seems to me that only
> Adobe and us took part in this discussion.
>
> I tend to vote against shipping this feature at present, as far as no spec
> is written, and no other browser vendors agree with it yet. I think it
> violates our guidelines. [1]
>
> [1]
>
> https://wiki.mozilla.org/WebAPI/ExposureGuidelines#When_is_an_API_ready_to_be_shipped_by_Gecko.3F
>
> - 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: Intent to implement and ship: CSS and SVG filters for canvas 2D

[Robert O'Callahan]

On Tue, Jun 16, 2015 at 11:05 AM, Xidorn Quan  wrote:

> On Tue, Jun 16, 2015 at 3:15 AM, Markus Stange 
> wrote:
>
> > Summary: The "filter" property on CanvasRenderingContext2D allows authors
> > to specify a filter that will get applied during canvas drawing. It
> accepts
> > the same values as the CSS "filter" property, so CSS filter shorthand
> > functions, references to SVG filters, and chained combinations of the
> two.
> >
>
> Is there any signal from other browser vendors? It seems to me that only
> Adobe and us took part in this discussion.
>
> I tend to vote against shipping this feature at present, as far as no spec
> is written, and no other browser vendors agree with it yet. I think it
> violates our guidelines. [1]
>
> [1]
>
> https://wiki.mozilla.org/WebAPI/ExposureGuidelines#When_is_an_API_ready_to_be_shipped_by_Gecko.3F


I think we're not quite there yet, but we're very close. There are two
things I want before we ship:
-- Get normative spec text up somewhere.
-- Get a signal from some other browser vendor that they're OK with this
feature. That no-one objected in WHATWG is a good sign. I've reached out to
a Blnk danvas dev for a slightly stronger signal.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: CSS and SVG filters for canvas 2D

[Xidorn Quan]

On Tue, Jun 16, 2015 at 9:23 AM, Robert O'Callahan 
wrote:

>
> On Tue, Jun 16, 2015 at 11:05 AM, Xidorn Quan 
> wrote:
>
>> On Tue, Jun 16, 2015 at 3:15 AM, Markus Stange 
>> wrote:
>>
>> > Summary: The "filter" property on CanvasRenderingContext2D allows
>> authors
>> > to specify a filter that will get applied during canvas drawing. It
>> accepts
>> > the same values as the CSS "filter" property, so CSS filter shorthand
>> > functions, references to SVG filters, and chained combinations of the
>> two.
>> >
>>
>> Is there any signal from other browser vendors? It seems to me that only
>> Adobe and us took part in this discussion.
>>
>> I tend to vote against shipping this feature at present, as far as no spec
>> is written, and no other browser vendors agree with it yet. I think it
>> violates our guidelines. [1]
>>
>> [1]
>>
>> https://wiki.mozilla.org/WebAPI/ExposureGuidelines#When_is_an_API_ready_to_be_shipped_by_Gecko.3F
>
>
> I think we're not quite there yet, but we're very close. There are two
> things I want before we ship:
> -- Get normative spec text up somewhere.
> -- Get a signal from some other browser vendor that they're OK with this
> feature. That no-one objected in WHATWG is a good sign. I've reached out to
> a Blnk danvas dev for a slightly stronger signal.
>

Yeah, those are things I want as well. Once we get them, I think it's fine
to ship.

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

Re: Intent to implement and ship: Unprivilaged WEBGL_debug_renderer_info

[Chris Peterson]

On 6/15/15 4:16 PM, Jeff Gilbert wrote:

Web Developer Use-Cases:
* Sites can collate and cross-reference drivers and hardware when tracking
issues both user-reported and auto-detected, which both helps sites
identify problematic hardware, and helps browsers fix these issues in turn.


YouTube currently collects WEBGL_debug_renderer_info when (Chrome or IE) 
users submit problem reports. They have offered to share these GPU 
correlations with Mozilla's video team.


This information would have been a huge time saver when we worked with 
YouTube to switch Firefox users from Flash to HTML5 video. We ran into 
many GPU driver bugs, from crashes to empty video frames, but we had no 
way to correlate these bug reports with specific GPUs or driver versions 
except through working with patient testers on Reddit.



chris

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

Re: Intent to implement and ship: CSS and SVG filters for canvas 2D

[Robert O'Callahan]

On Tue, Jun 16, 2015 at 11:23 AM, Robert O'Callahan 
wrote:

> I think we're not quite there yet, but we're very close. There are two
> things I want before we ship:
> -- Get normative spec text up somewhere.
> -- Get a signal from some other browser vendor that they're OK with this
> feature. That no-one objected in WHATWG is a good sign. I've reached out to
> a Blnk danvas dev for a slightly stronger signal.
>

I got a reply from that Blink dev saying that they want this feature, want
to implement it soon, and just need spec text.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: CSS and SVG filters for canvas 2D

[Markus Stange]

On 2015-06-15 8:15 PM, Robert O'Callahan wrote:

On Tue, Jun 16, 2015 at 11:23 AM, Robert O'Callahan 
wrote:


I think we're not quite there yet, but we're very close. There are two
things I want before we ship:
-- Get normative spec text up somewhere.
-- Get a signal from some other browser vendor that they're OK with this
feature. That no-one objected in WHATWG is a good sign. I've reached out to
a Blnk danvas dev for a slightly stronger signal.



I got a reply from that Blink dev saying that they want this feature, want
to implement it soon, and just need spec text.


That's great news, thanks for asking them!

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

Re: Intent to implement and ship: Unprivilaged WEBGL_debug_renderer_info

[Jeff Muizelaar]

I'm concerned this will discourage websites from reporting WebGL
issues because it will be easier just to block whatever device has the
problem they're running in to. This creates an additional burden on
the web developer and essentially creates the user agent problem all
over again, but at much worse scale because of the wide range of
possible devices. This may be manageable for very large developers
like Google but I don't think it scales across web developers. We are
typically in a better position to control and update any WebGL
blacklist.

I've suggested that creating an easy way to rely diagnostic
information to a website in the event of a problem is a better
solution for improving the overall quality of our WebGL implementation
and sharing that benefit with all websites instead of just benefiting
large properties like Google's.

-Jeff

On Mon, Jun 15, 2015 at 7:16 PM, Jeff Gilbert  wrote:
> Summary:
> The WEBGL_debug_renderer_info extension allows for querying which driver
> (and commonly GPU) a WebGL context is running on. Specifically, it allows
> querying the RENDERER and VENDOR strings of the underlying OpenGL driver.
>
> By default, RENDERER and VENDOR queries in WebGL yield safe but useless
> values. (For example, Gecko returns "Mozilla"/"Mozilla" for
> RENDERER/VENDOR) Queries to UNMASKED_RENDERER_WEBGL and
> UNMASKED_VENDOR_WEBGL yield the RENDERER and VENDOR string of the
> underlying graphics driver. These values are combined to form the "WebGL
> Renderer" field in about:support. On my system, these are:
> * UNMASKED_RENDERER_WEBGL: "ANGLE (NVIDIA GeForce GT 750M Direct3D11 vs_5_0
> ps_5_0)"
> * UNMASKED_VENDOR_WEBGL: "Google Inc." [1]
>
> Bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1171228
>
> Link To Standard:
> https://www.khronos.org/registry/webgl/extensions/WEBGL_debug_renderer_info/
>
> Do other browser engines implement this:
> Chrome and IE implement this; Safari does not.
>
> Platform Coverage: All platforms.
>
> Current Target Release: Firefox 41
>
> Related Preferences:
> * "webgl.disable-debug-renderer-info" (default: false): Disable this
> extension for unprivileged content.
> * "webgl.renderer-string-override" (default: ""): Overrides
> UNMASKED_RENDERER_WEBGL query result when non-empty.
> * "webgl.vendor-string-override" (default: ""): Overrides
> UNMASKED_VENDOR_WEBGL query result when non-empty.
>
> Security and Privacy Concerns:
> * Traditional user-agent sniffing concerns. (Known antipattern)
> * This info includes what GPU is being used, which may contribute to
> marketing profiles.
> * This info adds easily-accessible bits of entropy that improve
> fingerprinting, reducing privacy. (Panopticlick and others have
> demonstrated that this is already very effective)
>
> Web Developer Use-Cases:
> * Sites can more easily and immediately identify and address concerns
> caused by specific hardware or drivers. Currently, apps must
> unconditionally workaround an issue until we can ship a fix via browser
> updates.This can mean performance degradation for unaffected machines for,
> sometimes for weeks.
> * Sites can collate and cross-reference drivers and hardware when tracking
> issues both user-reported and auto-detected, which both helps sites
> identify problematic hardware, and helps browsers fix these issues in turn.
> * This allows sites to offer better estimates of performance, and offer
> reasonable defaults for quality settings.
>
> [1] On Windows, we use ANGLE as an intermediary driver on top of D3D, hence
> the VENDOR string being "Google, Inc." and not "NVIDIA" here.
> ___
> 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: Intent to implement and ship: Unprivilaged WEBGL_debug_renderer_info

[Ehsan Akhgari]

Further to what Jeff suggested, I know that we resisted shipping this 
feature when Google initially proposed it.  What has changed since then 
that we are considering changing our previous stance here?


On 2015-06-15 9:18 PM, Jeff Muizelaar wrote:

I'm concerned this will discourage websites from reporting WebGL
issues because it will be easier just to block whatever device has the
problem they're running in to. This creates an additional burden on
the web developer and essentially creates the user agent problem all
over again, but at much worse scale because of the wide range of
possible devices. This may be manageable for very large developers
like Google but I don't think it scales across web developers. We are
typically in a better position to control and update any WebGL
blacklist.

I've suggested that creating an easy way to rely diagnostic
information to a website in the event of a problem is a better
solution for improving the overall quality of our WebGL implementation
and sharing that benefit with all websites instead of just benefiting
large properties like Google's.

-Jeff

On Mon, Jun 15, 2015 at 7:16 PM, Jeff Gilbert  wrote:

Summary:
The WEBGL_debug_renderer_info extension allows for querying which driver
(and commonly GPU) a WebGL context is running on. Specifically, it allows
querying the RENDERER and VENDOR strings of the underlying OpenGL driver.

By default, RENDERER and VENDOR queries in WebGL yield safe but useless
values. (For example, Gecko returns "Mozilla"/"Mozilla" for
RENDERER/VENDOR) Queries to UNMASKED_RENDERER_WEBGL and
UNMASKED_VENDOR_WEBGL yield the RENDERER and VENDOR string of the
underlying graphics driver. These values are combined to form the "WebGL
Renderer" field in about:support. On my system, these are:
* UNMASKED_RENDERER_WEBGL: "ANGLE (NVIDIA GeForce GT 750M Direct3D11 vs_5_0
ps_5_0)"
* UNMASKED_VENDOR_WEBGL: "Google Inc." [1]

Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1171228

Link To Standard:
https://www.khronos.org/registry/webgl/extensions/WEBGL_debug_renderer_info/

Do other browser engines implement this:
Chrome and IE implement this; Safari does not.

Platform Coverage: All platforms.

Current Target Release: Firefox 41

Related Preferences:
* "webgl.disable-debug-renderer-info" (default: false): Disable this
extension for unprivileged content.
* "webgl.renderer-string-override" (default: ""): Overrides
UNMASKED_RENDERER_WEBGL query result when non-empty.
* "webgl.vendor-string-override" (default: ""): Overrides
UNMASKED_VENDOR_WEBGL query result when non-empty.

Security and Privacy Concerns:
* Traditional user-agent sniffing concerns. (Known antipattern)
* This info includes what GPU is being used, which may contribute to
marketing profiles.
* This info adds easily-accessible bits of entropy that improve
fingerprinting, reducing privacy. (Panopticlick and others have
demonstrated that this is already very effective)

Web Developer Use-Cases:
* Sites can more easily and immediately identify and address concerns
caused by specific hardware or drivers. Currently, apps must
unconditionally workaround an issue until we can ship a fix via browser
updates.This can mean performance degradation for unaffected machines for,
sometimes for weeks.
* Sites can collate and cross-reference drivers and hardware when tracking
issues both user-reported and auto-detected, which both helps sites
identify problematic hardware, and helps browsers fix these issues in turn.
* This allows sites to offer better estimates of performance, and offer
reasonable defaults for quality settings.

[1] On Windows, we use ANGLE as an intermediary driver on top of D3D, hence
the VENDOR string being "Google, Inc." and not "NVIDIA" here.
___
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: Intent to implement and ship: Unprivilaged WEBGL_debug_renderer_info

[Mike Hommey]

On Mon, Jun 15, 2015 at 04:39:50PM -0700, Chris Peterson wrote:
> On 6/15/15 4:16 PM, Jeff Gilbert wrote:
> >Web Developer Use-Cases:
> >* Sites can collate and cross-reference drivers and hardware when tracking
> >issues both user-reported and auto-detected, which both helps sites
> >identify problematic hardware, and helps browsers fix these issues in turn.
> 
> YouTube currently collects WEBGL_debug_renderer_info when (Chrome or IE)
> users submit problem reports. They have offered to share these GPU
> correlations with Mozilla's video team.
> 
> This information would have been a huge time saver when we worked with
> YouTube to switch Firefox users from Flash to HTML5 video. We ran into many
> GPU driver bugs, from crashes to empty video frames, but we had no way to
> correlate these bug reports with specific GPUs or driver versions except
> through working with patient testers on Reddit.

Isn't that the kind of correlation that should happen on our end, and
not rely on individual sites doing it, though? (which, in practice,
means one specific site)

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

Runtime Hardware Testing for Firefox Desktop

[Jet Villegas]

Bug 1156135  will
enable Runtime Hardware Testing for Firefox Desktop. Once enabled, we'll
test the rendering capabilities of the current user's hardware prior to
enabling features that depend on that hardware.

A more detailed overview is posted here:
https://wiki.mozilla.org/Performance/Runtime_Hardware_Testing

This is just one step toward the goal to reduce the need for chemspills due
to untested GPU/driver combinations that are incompatible with hardware-enabled
rendering features. Multiple teams at Mozilla are collaborating on this
program, and we need your help for this to succeed.

As this feature rides the trains on Nightly, we'll monitor the telemetry
reporting the hardware/driver combinations that fail to render. We'll use
this information to improve our error correction, and optimize the user
experience. Once we land, you may see a very brief Rendering Test after a
Firefox update. We compare the results of that test with a known good
rendering to determine if your system is capable of using GPU-enabled
features. We're now testing with known-bad configurations, but we need to
ensure that we avoid false positives with the Nightly population.

We'll post detailed instructions on how to report problems before we enable
this feature. Please report any problems you encounter or other feedback to
runtime-hardware-test...@mozilla.com

Thanks,

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