[desktop] Bugs logged by Desktop Release QA in the last 7 days

2019-11-25 Thread Mihai Boldan

Hello,

Here's the list of new issues found and filed by the Desktop Release QA 
team in the last 7 days.
Additional details on the team's priorities last week, as well as the 
plans for the current week are available at: https://tinyurl.com/y2atdpjj.

Bugs logged by Desktop Release QA in the last 7 days:
*
*Firefox: Address Bar
* NEW - https://bugzil.la/1597672 - Search suggestions are displayed 
after visiting a website with keyword.enabled is set to false


Firefox: File Handling
* RESOLVED FIXED - https://bugzil.la/1597963 - The file does not have an 
app associated with it for performing this action error when opening 
.ttf extensions through download panel


Firefox: Protections UI
* NEW - https://bugzil.la/1597322 - [macOS] Color tone inconsistency on 
links in about:protections page when system dark theme is set


Firefox: Security
* NEW - https://bugzil.la/1597230 - Removing Firefox from the app 
restriction list makes it disappear from the app list
* NEW - https://bugzil.la/1597234 - Websites are not blocked for a 
windows child user account
* NEW - https://bugzil.la/1597244 - An error is received when loading a 
website with a smart card installed certificate


Firefox: Theme
* NEW - https://bugzil.la/1598614 - [aarch 64] The browser controls are 
not correctly displayed while using high contrast theme


Core: Networking: DNS
* NEW - https://bugzil.la/1597729 - Requests sent for domains that are 
part of the DNS suffix list are reaching the DOH-proxy server
* NEW - https://bugzil.la/1598575 - DNS search suffix list is not being 
parsed by Firefox if set via gpedit
* NEW - https://bugzil.la/1598676 - [OSX] Domains that are part of the 
DNS suffix list are being handled via TRR


Core: WebRTC: Networking
* RESOLVED FIXED - https://bugzil.la/1598001 - Set 
media.peerconnection.ice.obfuscate_host_addresses.whitelist as a default 
pref


Core: Widget: Win32
* NEW - https://bugzil.la/1598573 - [Windows 7] The browser window 
controls are cut off with high dpi


DevTools: Console
* NEW - https://bugzil.la/1598297 - Task Cancel empty and expandable 
when blocking requests inside the Browser Console


DevTools: Netmonitor
* NEW - https://bugzil.la/1598275 - Netmonitor - Raw headers button - 
click area not contained
* NEW - https://bugzil.la/1598280 - Netmonitor - Raw headers button 
styling not applied on macOS on toggle


DevTools: What's New
* NEW - https://bugzil.la/1598621 - What's new in DevTools - 
TAB_navigation issues


Firefox Build System: General
* NEW - https://bugzil.la/1598650 - TestDllInterceptor.exe test failed 
on Windows 8x64


This is available as a Bugzilla bug list as well: 
https://tinyurl.com/r5wtfqg.


Regards,
Mihai Boldan


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


Opt your try pushes into Pernosco

2019-11-25 Thread Andrew Halberstadt
Hi everyone,

As of now, you can opt-in to Pernosco  analysis on your
try pushes by running:

$ ./mach try fuzzy --pernosco

or:

$ ./mach try chooser --pernosco

For those who are unaware, Pernosco is a debugging service built on top of
rr. It will analyze your try push for failures, attempt to record the
failures
with rr, then e-mail you a link to a live debugging session. Allow a few
hours
after your task has finished for the Pernosco recording to complete.

There are several limitations:

1. It only works with Linux x64 debug tests
2. Failure should be reproducible (otherwise the recording might not
capture it)
3. An @mozilla.com e-mail address is required to log-in to the service
(./mach
try will fail early if you don't have this)
4. Artifact builds are not yet supported (see bug 1598142
)

Previously we were using a whitelist of developers to control which pushes
were
analyzed. For now this whitelist continues to exist. If you are on it, you
can opt
out of Pernosco by passing in `--no-pernosco`.

Thanks to Kyle Huey for updating the Pernosco infrastructure to support this
flag.

Let me know if you have any questions.
Cheers,
Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Intent to prototype: Delegate and restrict permission in third party context

2019-11-25 Thread Thomas Nguyen
Summary: People don’t have a good understanding of iframes, because
generally, no UI indicates that iframes are visible on a page, or what
their origin is. Permission requests from iframes cause significant
confusion for users because it is hard to determine where the requests come
from, as the address bar does not match the site in the permission prompt.

Currently, Firefox allows iframes on a site to make permission requests and
show up a permission prompt using the origin of the iframes. A user making
a decision based on the third party context presented in the notification
prompt is complicated and confusing. This confusion is exacerbated when
managing previously stored permission decisions.

To address this problem, we would like to impose a restriction on
permissions coming from third party context. There would be two main
changes proposed:

   -

   Give an ability to delegate permissions from first party to third party
   embedded iframes, and impose a restriction to embedded iframes to request
   permission only when the iframe’s embedder has explicitly delegated it. The
   permission request will use the top level origin to show in the prompt,
   then users are only required to make permission decisions about the first
   party context.
   -

  This change is dependent on the ability of Feature Policy to disable
  permissions by default in cross-origin iframes. It will require a site to
  explicitly allow permissions for cross-origin iframes (setting allow
  attribute, e.g allow=”geolocation”) otherwise, the permission
requests will
  be denied on that iframes.
  -

  The change will be applied to geolocation, camera, microphone and
  screen-sharing permission, and fullscreen request.


   -

   Completely deny permissions from third party context for vibration,
   notification, and persistent-storage permission.


The plan is:

   -

   Enable Feature Policy allow attribute.
   -

   Make permission camera/microphone/geolocation/display-capture/fullscreen
   disabled by default in third-party iframe.
   -

   Delegate Permissions: only cross-origin iframes that have explicit
   delegated permission from their parent through the allow attribute will
   have the right to make permission requests.
   -

   Reduce the number of supported features to geolocation, camera,
   microphone screen-sharing, and fullscreen (the above features are supported
   for permissions UI with notification prompts, except fullscreen). And we
   will move all other features to experimental phrase under a user preference
   which is disabled by default.
   -

   Simplify prompts/dialogs to only contain the top-level origin.
   -

   Deny vibration, persistent-storage permission from third party iframe
   (notification permission was disabled in third party context,  just do some
   minor refactors).




Bug: The tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=1572461

Standard: Feature Policy
https://w3c.github.io/webappsec-feature-policy/#iframe-allow-attribute

Platform coverage: All.

Preference:

dom.security.featurePolicy.experimental.enabled: disabled by default, we
will limit supported features in Feature Policy to geolocation, camera,
microphone, fullscreen, display-capture and move others to experimental
phase.

permissions.delegate.enabled: enabled by default

dom.security.featurePolicy.enabled: this pref is implemented in Firefox 65
but enabled by default in Nightly only

Other browsers: Chrome supports permission delegation from Chrome 71.

web-platform-tests: We only have web platform tests for feature policy but
not permission delegation

Some of Feature Policy web-platform-tests that the permissions are disabled
by default in cross origin iframe:

https://searchfox.org/mozilla-central/source/testing/web-platform/meta/feature-policy

testing /web-platform
/tests
/
permissions

/feature-policy-permissions-query.html


testing /web-platform
/tests
/
mediacapture-streams

/MediaStream-default-feature-policy.https.html


testing/web-platform/tests/mediacapture-streams/MediaDevices-enumerateDevices-not-allowed-mic.https.html