Intent to remove: WebVR on insecure contexts

[Kearwood Kip Gilbert]

Summary: 
WebVR on insecure contexts (i.e. web sites served over non-HTTPS) is deprecated 
and will soon stop working in Firefox. 

Sites wanting to use WebVR should switch to HTTPS if they have not already. 

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

Link to standard: 
https://w3c.github.io/webvr/spec/1.1/

WebVR is a powerful feature that exposes sensor inputs that can capture 
biometric data (ie. distance of eyes to ground when user is standing).  
Immersive WebVR sites must be inherently trusted with this information.  The 
risks are greater if the transport is not encrypted.

Timeframe: 
We will immediately remove WebVR on insecure origins in FF59’s Nightly.  This 
should give developers some time to test their sites in Nightly until it rides 
the trains to FF59 in release.  WebVR is enabled by default in release FF57 and 
can be used to access insecure sites until they are updated.


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

Intent to ship: WebVR on macOS

[Kearwood Kip Gilbert]

As of 2017-10-01, I intend to turn WebVR on by default for macOS.  It has been 
developed behind the dom.vr.enabled preference.  We have already shipped WebVR 
by default for the Windows platform.  macOS support has been implemented for 
several months but disabled by default.  Our WebVR implementation supports 
OpenVR for the HTC Vive on macOS High Sierra, which is now hitting release.
This feature was previously discussed in this "intent to implement" thread: 
. 
Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1374399
Link to standard: https://w3c.github.io/webvr/spec/1.1/
Testing: 
Automated tests have been implemented and are already active for the macOS 
builds in taskcluster.  Platform conformance tests are shared with other UA’s.

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

RE: Intent to remove: sensor APIs

[Kearwood Kip Gilbert]

Please note that disabling the Device Orientation API will also effectively 
disable the “WebVR Polyfill”.  The “WebVR Polyfill” is a javascript library 
that allows browser that otherwise don’t support VR (ie, Fennec) to use 
“Cardboard” VR holders to create simple VR experiences.  Usage of these VR 
holders with non-VR capable browsers is quite prolific, with these holders 
found in most department stores.

The WebVR API when implemented directly by the browser (ie. Firefox Desktop) 
negates the need of the Device Orientation API, as it exposes the tracking data 
from the VR positional sensors in a more direct fashion.

A non-VR use case that affects 90% of users is the “magic window” effects.  
These are most commonly used by sites such as Facebook to give some degree of 
freedom in viewing a 360 panorama video or photo by moving the phone around.

Combined with media capture API’s the orientation API is also essential for 
implementing things like “Google Goggle” or Yelp’s Monocle on the web platform.

Cheers,
- Kip


From: Enrico Weigelt, metux IT consult
Sent: July 24, 2017 1:35 PM
To: Ben Kelly; Anne van Kesteren
Cc: dev-platform
Subject: Re: Intent to remove: sensor APIs

On 24.07.2017 13:57, Ben Kelly wrote:
 > On Mon, Jul 24, 2017 at 5:10 AM, Anne van Kesteren  
wrote:
 >
 >> * Device orientation
 >>
 >
 > Isn't this one required to build a decent web experience on mobile 
for some
 > sites?

Could you please define "decent web experience" ?

Maybe I'm just old, but I absolutely don't want an website know anything
about my local devices. Window size and resolution is fine, but ambient
conditions seriously crossed the red line of what I'd ever allow on my
machines.

I've already started patching out that stuff.

Same for things like USB devices, or all that "cloud" stuff.


--mtx

___
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: Profiling nightlies on Mac - what tools are used?

[Kearwood Kip Gilbert]

I would add to this Apple’s “OpenGL Profiler”:

https://developer.apple.com/library/content/technotes/tn2178

Cheers,
- Kip

From: Bobby Holley
Sent: June 19, 2017 3:08 PM
To: Chris Cooper
Cc: dev-platform@lists.mozilla.org
Subject: Re: Profiling nightlies on Mac - what tools are used?

Instruments is the big one that I'm aware of.

On Mon, Jun 19, 2017 at 3:03 PM, Chris Cooper  wrote:

> Hey all,
>
> The build peers are looking to change the way that nightlies are created
> on Mac as we switch to cross-compilation. Specifically, we're looking at
> stripping the nightlies to avoid an as-of-yet undiagnosed performance
> discrepancy vs native builds[1], but also to make the nightly configuration
> match what we ship on beta/release (stripped).
>
> Of course, stripping removes the symbols, and while we believe we have a
> solution for re-acquiring symbols that works for the Gecko Profiler, we
> realize
> that people out there may be using other profiling tools.
>
> If you profile on Mac, now is your chance to speak up. What other
> profiling tools do you use that we should be aware of?
>
> cheers,
> --
> coop
>
> 1. https://bugzilla.mozilla.org/show_bug.cgi?id=1338651
> ___
> 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: Running mochitest on packaged builds with the sandbox

[Kearwood Kip Gilbert]

+cc Diego, who has experimented with packaging Firefox on Steam...

Thanks Alex,

It sounds as though we can work around all of these issues, based on your 
feedback.  I believe that we could proxy any file access needed by the content 
process.  The main process will need to access some resources in these builds 
that are not normally accessed by the normal Firefox builds for the Steam 
integration.  Perhaps opening these resources isn’t too much concern for the 
regular Firefox builds.  If not, we could perhaps select these alternate 
sandboxing rules with a command-line parameter?

We have also explored treating this “Steam VR Browser” as a separate product, 
and using compile-time flags to select the desired code to build and assets.  
We could still hard-code the rules, but skip them at build time for regular 
Firefox builds.  In this case, we are effectively forking the “browser” 
directory into a “vrbrowser” and stripping it down to just what we need.

We liked the re-pack option (ie. Similar to QBRT), as we don’t have to put as 
much load on our test infrastructure; however, this is still an option on the 
table if a dedicated build and the associated costs is justified.

Cheers,
- Kearwood “Kip” Gilbert

From: Alex Gaynor
Sent: May 9, 2017 7:58 AM
To: Kearwood Kip Gilbert
Cc: dev-platform@lists.mozilla.org
Subject: Re: Running mochitest on packaged builds with the sandbox

Hi,
Hmm, VR appears to be an interesting challenge.

To expand a bit more on why mochitest+sandboxing is a challenge for packaged 
builds: The way mochitest is set up is that there's a configuration file which 
points to JS files to be loaded for tests. These are loaded by the content 
process. This works ok in non-packaged builds, because in those builds we allow 
read access to the entire source directory ("topsrcdir"); in packaged builds, 
we don't have this whitelist -- we only allow read access inside of the .app 
(to use the macOS lingo), so essentially content is trying to open a random JS 
file, and is blocked.
With that context, disabling sandboxing might be one option, another is for 
your repack to include the mochitest JS files inside the packaged build, then 
everything can work ok. We don't want to do this for general packaged builds 
because there's no reason for SuperPowers.js (for example) to be in a shipped 
FF, but if you're doing a special pack for testing it might make sense.
Does that make sense?
For your other question, about configuration of sandboxing rules. Right now we 
have the ability to have multiple different sets of sandbox rules, for example 
plugin processes and content processes have different sandbox rules, and so 
will GPU processes soon. With that said, it sounds like what you're talking 
about is really in the content process -- for that case, you're really better 
off remoting access to these resources through the parent process. This keeps 
us from expanding the attack surface in content (which is most exposed to the 
dangerous web), right now we're doing all we can to restrict this, so I 
wouldn't be excited about opening it back up :-)
Cheers,
Alex

On Mon, May 8, 2017 at 2:14 PM, Kearwood Kip Gilbert <kgilb...@mozilla.com> 
wrote:
Hi all,
 
The VR team is working on a Steam packaged browser with a VR specific UI and 
richer VR experience.  In order to prevent the overhead of having the VR 
specific assets included in every Firefox build while still running on tested 
executables, we will be doing a repack build.
 
WebVR will still continue to be supported in the regular Firefox builds; API 
surface area is the same in normal desktop builds.  Mochitests validating these 
API calls should be unaffected.
 
We will need a means for testing the VR frontend and assets that are added with 
the re-pack.  Ideally, we could use the existing test mechanisms, including 
mochitests.
 
Perhaps we could disable the sandbox for these front-end tests?
 
The Steam packaged builds will also need slightly expanded access to resources 
such as files, registry, and pipes required for communication with Steam.
 
Are there any plans to make the sandboxing rules configurable at runtime?
 
Cheers,
• Kearwood “Kip” Gilbert
 
 
From: Alex Gaynor
Sent: May 8, 2017 10:26 AM
To: dev-platform@lists.mozilla.org
Subject: Running mochitest on packaged builds with the sandbox
 
Hi dev-platform,
 
Top-line question: Do you rely on being able to run mochitests from a
packaged build (`--appname`)?
 
Context:
 
The sandboxing team has been hard at work making the content process
sandbox as restrictive as possible. Our latest focus is  removing file read
permissions from content processes -- the sandbox's value is pretty limited
if a compromised content process can ship all your files off by itself!
 
One of the things we've discovered in the process of developing these
patches is that they break running mochitest on packaged firefox builds
(this is the `--appname` flag to mochitest)! `try` doesn

RE: Running mochitest on packaged builds with the sandbox

[Kearwood Kip Gilbert]

Hi all,

The VR team is working on a Steam packaged browser with a VR specific UI and 
richer VR experience.  In order to prevent the overhead of having the VR 
specific assets included in every Firefox build while still running on tested 
executables, we will be doing a repack build.

WebVR will still continue to be supported in the regular Firefox builds; API 
surface area is the same in normal desktop builds.  Mochitests validating these 
API calls should be unaffected.

We will need a means for testing the VR frontend and assets that are added with 
the re-pack.  Ideally, we could use the existing test mechanisms, including 
mochitests.

Perhaps we could disable the sandbox for these front-end tests?

The Steam packaged builds will also need slightly expanded access to resources 
such as files, registry, and pipes required for communication with Steam.

Are there any plans to make the sandboxing rules configurable at runtime?

Cheers,
- Kearwood “Kip” Gilbert


From: Alex Gaynor
Sent: May 8, 2017 10:26 AM
To: dev-platform@lists.mozilla.org
Subject: Running mochitest on packaged builds with the sandbox

Hi dev-platform,

Top-line question: Do you rely on being able to run mochitests from a
packaged build (`--appname`)?

Context:

The sandboxing team has been hard at work making the content process
sandbox as restrictive as possible. Our latest focus is  removing file read
permissions from content processes -- the sandbox's value is pretty limited
if a compromised content process can ship all your files off by itself!

One of the things we've discovered in the process of developing these
patches is that they break running mochitest on packaged firefox builds
(this is the `--appname` flag to mochitest)! `try` doesn't appear to use
this, and none of us use it in our development workflows, but we wanted to
check in with dev-platform and see if we were going to be breaking people's
development flows! While these restrictions are not on by default yet, once
they are you'd only be able to run tests on packaged builds by disabling
the sandbox. If this is a fundamental part of lots of folks' workflows
we'll dig into whether there's a way to keep this working.

Happy Monday!
Alex
___
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 ship: WebVR on Windows in Release

[Kearwood "Kip" Gilbert]

We believe that we have addressed the remaining issues and we will turn WebVR 
on by default in Windows, shipping in Firefox 55.

After discussions with the other major browser vendors, we believe that we are 
all on track to ship a compatible version of the WebVR 1.1 draft specification 
and have addressed the issues brought up in this thread.

Additionally, Microsoft announced yesterday that their implementation (with 
whom we share Web Platform Tests) has just shipped with the Creators' Update:
https://blogs.windows.com/msedgedev/2017/04/11/introducing-edgehtml-15/ 
<https://blogs.windows.com/msedgedev/2017/04/11/introducing-edgehtml-15/>

We and other browser engines have expressed an intent to either support 1.1 via 
a polyfill of 2.0 or a side by side implementation, depending on what is easier 
from their engine. If there is very little uptake or we are able to transition 
users to 2.0, then we may be able to deprecate 1.1 entirely. We plan to have 
the discussion around that process in the group later next year, around the 
time when we expect 2.0 to be finalized.

Thanks everyone, within and beyond the MozVR team, for making this possible!

Cheers,

 - Kearwood “Kip” Gilbert

> On Mar 1, 2017, at 12:50 PM, kgilb...@mozilla.com wrote:
> 
> As of March 1, 2017 I intend to turn WebVR on by default on Windows.  It has 
> been developed behind the dom.vr.enabled preference and has been enabled by 
> default on Firefox Nightly and Dev Edition since November 2015.  Other UAs 
> shipping this include Samsung Internet Browser (Gear VR) and Oculus Carmel.  
> Microsoft Edge and Google Chrome are also intending to ship.  Google Chrome 
> has enabled WebVR on Android with an Origin Trial.
>  
> This feature was previously discussed in this "intent to ship" thread, for 
> non-release builds:
>  
> https://groups.google.com/d/topic/mozilla.dev.platform/BeVaHGEgZNA/discussion 
> <https://groups.google.com/d/topic/mozilla.dev.platform/BeVaHGEgZNA/discussion>
>  
> Bug to turn on by default:
>  
> https://bugzilla.mozilla.org/show_bug.cgi?id=1343368 
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1343368>
>  
> We will support Oculus and HTC Vive by default.  Oculus is already enabled; 
> HTC Vive support with OpenVR has been developed behind the 
> “dom.vr.openvr.enabled” preference and will be turned on with this bug:
>  
> https://bugzilla.mozilla.org/show_bug.cgi?id=1343374 
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1343374>
>  
> Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/ 
> <https://w3c.github.io/webvr/archive/prerelease/1.1/>
>  
> Since the initial implementation, a W3C working group was formed including 
> members from Mozilla, Google, Microsoft, Samsung, and Oculus.  The API has 
> stabilized and is frozen at "WebVR 1.1" while its successor "WebVR 2.0" is 
> being conceived.
>  
> Windows only support for WebVR would be enabled by default in Firefox 54.  
> OSX is not yet supported by current VR headsets.  Beta Linux support for HTC 
> Vive has very recently landed, and will be supported by Firefox after the 
> Firefox 54 uplift.
>  
> Cheers,
> Kearwood “Kip” Gilbert
> :kip

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

Request Feedback - Submitting Canvas Frames, WebVR Compositor

[Kearwood "Kip" Gilbert]

Hello All,

In order to support features in the WebVR 1.0 API 
(https://mozvr.com/webvr-spec/) and to improve performance for WebVR, I would 
like to implement an optimized path for submitting Canvas and OffscreenCanvas 
frames to VR headsets.  The WebVR 1.0 API introduces "VR Layers", explicit 
frame submission, and presenting different content to the head mounted display 
independently of the output the regular 2d monitor.  I would like some feedback 
on a proposed “VR Compositor” concept that would enable this.

What would be common between the “VR Compositor” and the regular “2d 
Compositor”?
- TextureHost and TextureChild would be used to transfer texture data across 
processes.
- When content processes crash, the VR Compositor would continue to run.
- There is a parallel between regular layers created by layout and “VR Layers”.
- There would be one VR Compositor serving multiple content processes.
- The VR Compositor would not allow unprivileged content to read back frames 
submitted by other content and chrome ux.
- Both compositors would exist in the “Compositor” process, but in different 
threads.

What is different about the “VR Compositor”?
- The VR Compositor would extend the PVRManager protocol to include VR Layer 
updates.
- The VR Compositor will not obscure the main 2d output window or require 
entering full screen to activate a VR Headset.
- In most cases, there will be no visible window created by the VR Compositor 
as the VR frames are presented using VR specific API’s that bypass the OS-level 
window manager.
- The VR Compositor will not run synchronously with a refresh driver as it can 
simultaneously present content with mixed frame rates.
- Texture updates submitted for VR Layers would be rendered as soon as 
possible, often asynchronously with other VR Layer updates.
- VR Layer textures will be pushed from both Canvas elements and 
OffscreenCanvas objects, enabling WebVR in WebWorkers.
- The VR compositor will guarantee perfect frame uniformity, with each frame 
associated with a VR headset pose frame explicitly passed into 
VRDisplay.SubmitFrame.  No frames will be dropped, even if multiple frames are 
sent within a single hardware vsync.
- For most devices (i.e. Oculus and HTC Vive), the VR Compositor will perform 
front-buffer rendering.
- VR Layers asynchronously move with the user’s HMD pose between VR Layer 
texture updates if given geometry and a position within space.
- The VR Compositor implements latency hiding effects such as Asynchronous Time 
Warp and Pose Prediction.
- The VR Compositor will be as minimal as possible.  In most cases, the VR 
Compositor will offload the actual compositing to the VR device runtimes.  
(Both Oculus and HTC Vive include a VR compositor)
- When the VR device runtime does not supply a VR Compositor, we will emulate 
this functionality.  (i.e. for Cardboard VR)
- All VR hardware API calls will be made exclusively from the VR Compositor’s 
thread.
- The VR Compositor will implement focus handling, window management, and other 
functionality required for Firefox to be launched within environments such as 
Oculus Home and SteamVR.
- To support backwards compatibility and fall-back views of 2d web content 
within the VR headset, the VR compositor could provide an nsWidget / nsWindow 
interface to the 2d compositor.  The 2d compositor output would be projected 
onto the geometry of a VR Layer and updated asynchronously with HMD poses.
- The VR Compositor will not allocate unnecessary resources until either WebVR 
Content is accessed or the browser is launched from within a VR-only 
environment such as Oculus home, SteamVR, or GearVR.

Early WIP patches of implementation of the WebVR 1.0 API are in Bug 1250244.  I 
expect the first implementation to be minimal, but lay the foundation that will 
eventually become the VR Compositor.  

Thanks for giving this a review — I look forward to your feedback!

Cheers,

 - Kearwood “Kip” Gilbert


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

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

[Kearwood "Kip" Gilbert]

On 2016-01-04 3:54 PM, Xidorn Quan wrote:
> On Tue, Jan 5, 2016 at 8:46 AM, Kearwood "Kip" Gilbert
> <kgilb...@mozilla.com> wrote:
>> Hello All,
>>
>> In WebVR, we often present UI as a Head's Up Display (HUD) that floats
>> in front of the user.  Additionally, we often wish to show 2d graphics,
>> video, and CSS animations as a texture in 3d scenes.  Creating these
>> textures is something that CSS and HTML are great at.
>>
>> Unfortunately, I am not aware of an easy and efficient way to capture an
>> animated of an interactive HTML Element and bring it into the WebGL
>> context.  A "moz-element" -like API would be useful here.
> Is it possible to access pixels' color inside the texture? If yes,
> please mind the privacy issue around :visited selector on links, as
> users' history would be leaked via either painting link directly, or
> painting an element using -moz-element(#a-link-element) as background.
Thanks Xidorn!

The proposed WEBGL_security_sensitive_resources extension describes how
we could ensure that content does not read pixels from buffers that were
rendered with security sensitive textures.

If we don't implement read-only buffers with
WEBGL_security_sensitive_resources, would it be sufficient to render
content styled without the :visited selector and not allow cross-origin
content?  Are there some other security concerns I may have missed?

Cheers,
 - Kip
>
> More information can be found in [1] and also [2].
>
> [1] 
> https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector
> [2] 
> https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Drawing_DOM_objects_into_a_canvas#Security
>
> - Xidorn

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

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

[Kearwood "Kip" Gilbert]

On 2016-01-04 4:46 PM, Robert O'Callahan wrote:
> On Tue, Jan 5, 2016 at 10:46 AM, Kearwood "Kip" Gilbert <
> kgilb...@mozilla.com> wrote:
>
>> In WebVR, we often present UI as a Head's Up Display (HUD) that floats
>> in front of the user.  Additionally, we often wish to show 2d graphics,
>> video, and CSS animations as a texture in 3d scenes.  Creating these
>> textures is something that CSS and HTML are great at.
>>
>> Unfortunately, I am not aware of an easy and efficient way to capture an
>> animated of an interactive HTML Element and bring it into the WebGL
>> context.  A "moz-element" -like API would be useful here.
>>
>> Perhaps we could solve this by implementing and extending the proposed
>> WEBGL_dynamic_texture extension:
>>
>>
>> https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_dynamic_texture/
>
> This proposal seems unnecessarily complex. Is there a way for me to send
> feedback?

There is a mailing list, public_we...@khronos.org:

https://www.khronos.org/webgl/public-mailing-list/

There is also a github repository with issues and pull requests:

https://github.com/KhronosGroup/WebGL/tree/master/extensions/proposals

>
> Essentially, we would extend the same API but allow the WDTStream
>> interface to apply to more HTML elements, not just HTMLCanvasElement,
>> HTMLImageElement, or HTMLVideoElement.
>>
>> We would also need to implement WEBGL_security_sensitive_resources to
>> enforce the security model:
>>
>>
>> https://www.khronos.org/registry/webgl/extensions/WEBGL_security_sensitive_resources/
>
> I wish I'd known about this proposal earlier! This looks pretty good,
> though I'd always thought this would be too complicated to spec and
> implement to be practical. Glad to be wrong! Although I think we should get
> as much feedback as possible on this in case of hidden gotchas.
>
> Does this sound like a good idea?  I feel that this is something that
>> all WebGL developers would want, as it would make building front-ends
>>
> for games much easier.
> Yes, I think together these would be very useful.
>
> If others feel the same, I would also like to follow up with a proposal
>> to make the captured HTML elements interactive through use of an
>> explicit "pick buffer" added to canvases.
>>
> How would that work? Being able to synthesize mouse (touch?) events in HTML
> elements would add another set of issues.
The intent is to enable content to work transparently with multiple
cursor models implemented at the platform level.  We wish the cursor to
remain responsive even if the page is not. 

As vertex shaders may be applied to elements and elements may be
occluded by other objects in a 3d scene, content needs to describe the
relationship between the original coordinate system of the elements and
the rendered output.  The proposed method of doing this is with a
pick-buffer.

A pick buffer can be viewed as a simple GPU accelerated raycasting
engine to the underlying scene.

A pick buffer is composed of an additional render target, which can be
either rendered in a separate pass or using WEBGL_draw_buffers in a
single pass.  Rather than interpreting the 32-bpp data as RGBA images
for display, the fragment shader will encode an object id and
interpolated uv coordinates.  When the user passes their mouse over the
canvas (or adjusts their gaze with a stereoscopic VR cursor), the
pick-buffer would be sampled and interpreted by platform-level code. 
The information within the sample would be used to identify the
underlying element (though an pick buffer id to element id lookup table)
as well as the coordinate within the un-transformed space of the element
to synthesize events on.

Security is a concern, as content may use this feature to obscure the
appearance of an element with discontinuity between the displayed buffer
and the pick buffer.  I would suggest that we enforce a CORS-like policy
that disables pick buffers unless all source textures used to render the
buffer came from sanitized inputs and are not cross-origin.

In the case of implementing a VR web browser with 2d backwards
compatibility, perhaps some restrictions can be relaxed in the case of
chrome-only access to the API.

To avoid performance overhead, the pick buffer could be rendered by
content at lower intervals or with a lower resolution than the rendered
output.
>
> I assume the idea of mixing CSS 3D-transformed elements into a WebGL scene
> has been rejected for some reason?
>
> Rob
Mixing CSS 3D-transformed elements into WebGL is still on the table;
however, this proposal is more future-proof enabling more expression in
content.  In the VR HUD case it is more ergonomic to present panels as
curved surfaces rather than flat planes.  When plac

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

[Kearwood "Kip" Gilbert]

On 2016-01-04 4:54 PM, Robert O'Callahan wrote:
> On Tue, Jan 5, 2016 at 1:18 PM, Jonas Sicking  wrote:
>
>> A big problem is sticking HTML/CSS content into WebGL is that WebGL
>> effectively enables reading pixel data through custom shaders and
>> timing attacks.
>>
> If you read
> https://www.khronos.org/registry/webgl/extensions/WEBGL_security_sensitive_resources/
> carefully I think it's designed to prevent timing attacks by forbidding
> shader control flow from depending on security-sensitive texture data.
>
> It's hard for me to judge how implementable it is, but in principle it
> should be doable. It requires analysis of shader code.
>
> Rob
Another vector to read back content is the depth buffer, glQueries, and
use of the discard instruction.  WEBGL_security_sensitive_resources
prevents writing to the depth buffer when binding a security sensitive
texture.

If it is not feasible to prevent variation in timing or to otherwise
prevent content from determining the content of the texture, perhaps
another approach would be to require all elements to be sanitized before
capturing their textures.  For example, :visited styles should not be
evaluated and cross-origin content should not be allowed.

- Kip

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

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

[Kearwood "Kip" Gilbert]

Thanks for your feedback, Jeff!

My comments below...

On 2016-01-04 2:50 PM, Jeff Gilbert wrote:
> WEBGL_dynamic_texture is due for a pruning refactor (I think I'm on
> the hook for this), so don't base anything on it as-is.
I'm glad I checked with you first.  I would be interested in any
alternatives that might be on the horizon.
>
> IIRC, we don't believe WEBGL_security_sensitive_resources is viably
> implementable in a safe way (timing attacks!), so I suggest ignoring
> it.
Perhaps enforcing a CORS-like model would be simpler to secure, by
limiting what content you can get handles for?
>
> Extending texture uploads to allow dom::Element uploads is easily done
> from a technical standpoint, but doing it efficiently will take novel
> non-trivial work. (not every dom::Element has a Layer/Image)
Agree.  Perhaps we could make the problem simpler by forcing an element
to have a layer when it is captured?  Perhaps similar to will-change.
>
> Adding picking to WebGL is a non-starter.
I suspect that most of the picking / interactivity could be implemented
in JS.  Some extensions may make this more efficient by enabling content
to perform picking asynchronously in a webworker with
WEBGL_shared_resources or perhaps by using glQuery and
EXT_disjoint_timer_query.

>
> From an API standpoint, it could be interesting to try to use
> ImageBitmaps as handles to snapshots of dom::Elements.
This is promising..  I'll explore this a bit.
>
> I think that it would be most efficient just to have a meeting about
> these topics, instead of iterating slower via email.

Sounds great, if you don't mind joining in.  I'll ping you and get
something set up.
>
> -Jeff
Thanks again, Jeff!

>
> On Mon, Jan 4, 2016 at 1:46 PM, Kearwood "Kip" Gilbert
> <kgilb...@mozilla.com> wrote:
>> Hello All,
>>
>> In WebVR, we often present UI as a Head's Up Display (HUD) that floats
>> in front of the user.  Additionally, we often wish to show 2d graphics,
>> video, and CSS animations as a texture in 3d scenes.  Creating these
>> textures is something that CSS and HTML are great at.
>>
>> Unfortunately, I am not aware of an easy and efficient way to capture an
>> animated of an interactive HTML Element and bring it into the WebGL
>> context.  A "moz-element" -like API would be useful here.
>>
>> Perhaps we could solve this by implementing and extending the proposed
>> WEBGL_dynamic_texture extension:
>>
>> https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_dynamic_texture/
>>
>> Essentially, we would extend the same API but allow the WDTStream
>> interface to apply to more HTML elements, not just HTMLCanvasElement,
>> HTMLImageElement, or HTMLVideoElement.
>>
>> We would also need to implement WEBGL_security_sensitive_resources to
>> enforce the security model:
>>
>> https://www.khronos.org/registry/webgl/extensions/WEBGL_security_sensitive_resources/
>>
>> Does this sound like a good idea?  I feel that this is something that
>> all WebGL developers would want, as it would make building front-ends
>> for games much easier.
>>
>> If others feel the same, I would also like to follow up with a proposal
>> to make the captured HTML elements interactive through use of an
>> explicit "pick buffer" added to canvases.
>>
>> I look forward to your feedback.
>>
>> Cheers,
>>   - Kearwood "Kip" Gilbert
>>
>> ___
>> 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

"-Moz-Element" -like API by extending WEBGL_dynamic_texture

[Kearwood "Kip" Gilbert]

Hello All,

In WebVR, we often present UI as a Head's Up Display (HUD) that floats
in front of the user.  Additionally, we often wish to show 2d graphics,
video, and CSS animations as a texture in 3d scenes.  Creating these
textures is something that CSS and HTML are great at.

Unfortunately, I am not aware of an easy and efficient way to capture an
animated of an interactive HTML Element and bring it into the WebGL
context.  A "moz-element" -like API would be useful here.

Perhaps we could solve this by implementing and extending the proposed
WEBGL_dynamic_texture extension:

https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_dynamic_texture/

Essentially, we would extend the same API but allow the WDTStream
interface to apply to more HTML elements, not just HTMLCanvasElement,
HTMLImageElement, or HTMLVideoElement.

We would also need to implement WEBGL_security_sensitive_resources to
enforce the security model:

https://www.khronos.org/registry/webgl/extensions/WEBGL_security_sensitive_resources/

Does this sound like a good idea?  I feel that this is something that
all WebGL developers would want, as it would make building front-ends
for games much easier.

If others feel the same, I would also like to follow up with a proposal
to make the captured HTML elements interactive through use of an
explicit "pick buffer" added to canvases.

I look forward to your feedback.

Cheers,
  - Kearwood "Kip" Gilbert

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

Re: APZ enabled on Fennec nightly

[Kearwood "Kip" Gilbert]

Excellent, Kats!!

Perhaps this will also unblock smooth scrolling and scroll snapping for fennec.

Cheers,
 - Kearwood “Kip” Gilbert

> On Nov 30, 2015, at 8:37 AM, Kartikaya Gupta <kgu...@mozilla.com> wrote:
> 
> Hi all,
> 
> Just a heads up that I landed the patch to enable APZ on Fennec
> (nightly channel only for now). It should be in the Dec 1 nightly and
> onwards. This will make scrolling around, and general touch input
> handling, feel different on Fennec. The main improvement should be
> that scrolling of iframes and overflow:scroll divs will be smoother
> and faster.
> 
> If you find bugs, or behaviour differences that you feel make things
> worse, please file them in the "Graphics, Panning and Zooming"
> component of the "Firefox for Android" component and we'll take a
> look.
> 
> Thanks!
> kats
> ___
> 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

Intent to ship: WebVR

[Kearwood "Kip" Gilbert]

As of Oct 29, 2015 I intend to turn WebVR on by default for all
platforms. It has been developed behind the dom.vr.enabled preference. 
A compatible API has been implemented (but not yet shipped) in Chromium
and Blink.

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1218482

Link to standard: https://mozvr.github.io/webvr-spec/webvr.html


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

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

[Kearwood Kip Gilbert]

I would defer to the expert on the subject:

https://imgflip.com/i/o5r8m

- Kip

On 2015-07-07 6:17 PM, David Anderson wrote:
 +1 for removing this. Gecko's use is inconsistent, and outside of Gecko code 
 that does use it, I've never seen it used in any other codebase. I've never 
 gone to another project and thought, I miss decorating everything in a way 
 that changes capitalization and impairs canonical naming.

 Reasons for using it in the first place are suspect. None of them seem to 
 justify the extra developer overhead or the odd variable names that result. I 
 can't imagine we've solved some massive readability problem unique to Gecko 
 or unsolved by other projects, or that we're catching important problems that 
 static analysis can't find.
 ___
 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: Largest chunks of code that are likely to be removable?

[Kearwood Kip Gilbert]

Would anyone be opposed to combining the Matrix4x4 class and gfx3DMatrix?  
Rather than adding support for transforms and projections that involve vertices 
behind the w=0 plane to gfx3DMatrix, it may be cleaner to refactor affected 
call-sites to use Matrix4x4 instead.  The remaining references to gfx3DMatrix 
would be very few and easily replaced as well.

Cheers,
  - Kip

 On Jun 29, 2015, at 11:19 PM, Nicholas Nethercote n.netherc...@gmail.com 
 wrote:
 
 Hi,
 
 I'm wondering what the largest chunks of code there are in the
 codebase that are candidates for removal, i.e. probably with a bit of
 work but not too much.
 
 One that comes to mind is rdf/ (see
 https://bugzilla.mozilla.org/show_bug.cgi?id=1176160#c5) though I
 don't have a good understanding of how much stuff depends on it, even
 having seen https://bugzilla.mozilla.org/show_bug.cgi?id=420506.
 
 Any other candidates for removal?
 
 Nick
 ___
 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

Intent to Ship: DEAA (Antialiasing) for CSS Transformed Layer Edges for the OpenGL Compositor (OSX and Linux)

[Kearwood Kip Gilbert]

As of April 24, 2015 I intent to turn on by default DEAA (Antialiasing)
for CSS transformed layer edges on OSX.  It has been developed behind
the layers.deaa.enabled preference.

Platform coverage:
This will be enabled for all desktop platforms that use the OpenGL
compositor back-end.  Currently, OSX is the only desktop platform with
the OpenGL compositor back-end enabled by default.  Once the OpenGL
compositor is enabled for Linux with Bug 594876, DEAA will become active
on Linux as well.

Mobile platforms will be enabled later, potentially through a white-list
system that will be populated with specific devices that meet
performance and compatibility criteria.

This feature was previously discussed in this intent to implement thread:

https://groups.google.com/d/msg/mozilla.dev.platform/XPCp_8iFxgM/paSHh-t4qyYJ

Bugs to turn on by default:

https://bugzilla.mozilla.org/show_bug.cgi?id=1152977  (OSX)
https://bugzilla.mozilla.org/show_bug.cgi?id=1152974 (Linux)

Link to standard:

This feature does not change any API's and takes effect automatically
for existing web content.  Other browsers have already shipped with this
enabled, using a similar DEAA implementation.

- Kearwood Kip Gilbert

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

Intent to Implement: DEAA (Antialiasing) for CSS Transformed Layer Edges

[Kearwood Kip Gilbert]

Summary:

Edges of layers with rotations and projections applied through CSS
transforms have stair-step, aliased edges.  Visiting the attached URL
demonstrates the aliasing effect.

Applying DEAA (Distance to Edge Anti-aliasing) for transformed layers
enables anti-aliasing without requiring viewport multi-sampling and
without performance impact when drawing layers that do not require it.

Bug:

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

Platform Coverage:

Android, Desktop, Firefox OS, Windows, OSX, Linux

There will be separate implementations for the OpenGL, D3D9, and D3D11
compositors.  The OpenGL compositor implementation of DEAA will be
enabled first, enabled by default on desktop platforms.  The DirectX
implementation will follow, enabling this for Windows.

Safari, Chrome, and IE have already enabled DEAA by default on Desktop,
so there should be little risk of performance issues.

Mobile platforms can benefit greatly from DEAA; however, we will need to
be selective on which hardware to enable this on to avoid performance
regressions.

Estimated or target release:

Early Q2 2015

Preferences behind which this will be implemented:

layers.opengl.deaa.enabled
layers.d3d9.deaa.enabled
layers.d3d11.deaa.enabled



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

Intent to Ship: CSS Scroll Snapping on Desktop

[Kearwood Kip Gilbert]

As of March 18, 2015 I intend to turn on by default CSS Scroll Snapping
on Desktop.  It has been developed behind the
layout.css.scroll-snap.enabled preference.  This feature has already
been enabled on B2G.

Platform coverage:
This has already been enabled on B2G (Firefox OS).  All desktop
platforms will be enabled once scroll bar support for CSS scroll
snapping lands (Bug 969250).  Fennec will be enabled once the C++ based
APZC implementation ships for Fennec (Bug 1138668).

This feature was previous discussed in this intent to implement thread:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/HX9lwWZ250o/discussion

Feedback during the draft updates on the css-snappoints specification
took place on the w3.org www-style mailing list.

Bug to turn on by default:

Bug 1138658 - Enable CSS Scroll Snapping by Default on Desktop

Link to standard:
http://dev.w3.org/csswg/css-snappoints/

The entirety of the W3 specification is implemented, with one
exception.  In section 4 (Scroll Snap Types: the 'scroll-snap-type'
property), the specification reads, If the content changes such that
the visual viewport would no longer rest on a snap point (e.g. content
is added, moved, deleted, resized), the scroll offset must be modified
to maintain this guarantee..  Support for this is tracked in Bug
1124324 (Perform instant and smooth scrolls to maintain guarantees set
by scroll snapping CSS attributes when content changes) and will be
landed separately.

 - Kearwood Kip Gilbert


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

Intent to ship: CSS Scroll Snapping on B2G / Firefox OS

[Kearwood Kip Gilbert]

As of March 3, 2014 I intend to turn on by default CSS Scroll Snapping
on B2G.  It has been developed behind the layout.css.scroll-snap.enabled
preference.  Firefox is the first UA to ship this feature.

Platform coverage: Initially, this will be enabled only on B2G (Firefox
OS).  Desktop platforms will be enabled once scroll bar support for CSS
scroll snapping lands (Bug 969250).  Fennec will be enabled once the C++
based APZC implementation ships for Fennec (Bug 1138668).

This feature was previous discussed in this intent to implement thread:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/HX9lwWZ250o/discussion

Feedback during the draft updates on the css-snappoints specification
took place on the w3.org www-style mailing list.

Bug to turn on by default:

Bug 1138651 - Enable CSS Scroll Snapping by Default on B2G

Link to standard:
http://dev.w3.org/csswg/css-snappoints/

The entirety of the W3 specification is implemented, with one
exception.  In section 4 (Scroll Snap Types: the 'scroll-snap-type'
property), the specification reads, If the content changes such that
the visual viewport would no longer rest on a snap point (e.g. content
is added, moved, deleted, resized), the scroll offset must be modified
to maintain this guarantee..  Support for this is tracked in Bug
1124324 (Perform instant and smooth scrolls to maintain guarantees set
by scroll snapping CSS attributes when content changes) and will be
landed separately.

 - Kearwood Kip Gilbert

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

Re: Detecting 32 or 64-bit Firefox build from privileged JS

[Kearwood Kip Gilbert]

I am a user of UltraSparc, but practically only for server-side
applications and verifying code to ensure it is written in the most
portable (endianness neutral) manner.  The Sparc Niagara and Niagara 2
are of particular interest as they are one of the few robust multi-core
GPL sourced processors.  (You can synthesize your own Ultrasparc on an
FPGA or ASIC).

Please note that Debian Sparc will default to a 32-bit userland even on
a 64-bit kernel, so there is a mix of both 64-bit and 32-bit Sparc
platforms in the wild.

Unfortunately, there are no longer any desktop form-factor Sparc
machines made commercially, so the actual users of a Sparc browser is
expected to be minimal.

With the advent of low-cost ARM based computers such as the Raspberry PI
2 and Odroid, I would anticipate more interest by users in that space,
who use them commonly as desktop replacements.  Perhaps it would be
useful to track the number of non-Android ARM users.

- Kearwood Kip Gilbert

On 2015-02-24 9:52 PM, ishikawa wrote:
 On 2015年02月24日 20:28, Kyle Huey wrote:
   I'm also not sure why you care about arcane architectures like
 Itanium, Alpha, and SPARC, since there are approximately zero users of
 those.

 - Kyle
 I think there are users of ultrasparc out there.
 But as long as SPARC is returned as the architecture,
 we can safely assume that 99.99% (or 99.%) of it is 64-bit.
 SunOS on ultrasparc is 64-bit for at least last dozen years if I recall
 correctly.
 (32-bit sparc CPU is very old.)

 ___
 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