Re: Remove browser and OS architecture from Firefox's User-Agent string?

2019-05-13 Thread Chris Peterson

On 5/11/2019 4:11 AM, j.j. wrote:

< "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101
Firefox/66.0"
  > "Mozilla/5.0 (Windows NT 10.0; rv:66.0) Gecko/20100101 Firefox/66.0"

Note that  "navigator.oscpu"  returns  "Windows NT 6.1; Win64; x64"  or 
similar. This needs to change then.



Yes. navigator.oscpu and the UA string share some common code, so they 
would both be fixed to match 32-bit Windows.


btw, navigator.platform has already been fixed to return "Win32" for 
Win32, WOW64, and Win64 Firefox builds (in bug 1472618).


navigator.platform returns:

Browser| Win32 OS | Win64 OS
---+--+-
IE11   | "Win32"  | "Win64"
Chrome | "Win32"  | "Win32"
Edge   | "Win32"  | "Win32" (changed to match Chrome)
Firefox 62 | "Win32"  | "Win64"
Firefox 63 | "Win32"  | "Win32" (changed in bug 1472618)

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


Changes to turning off e10s

2019-05-13 Thread Gijs Kruitbosch

(Cross-post: m-d-platform and firefox-dev)

Hello,

(If you don't care about turning off e10s, you can stop reading.)

At the end of last week I landed changes in
https://bugzilla.mozilla.org/show_bug.cgi?id=1548941
that may affect how you turn off e10s. The broad aim was to ensure that 
we stop grandfathering users into a non-e10s configuration which they 
should not run on a day-to-day basis, given that it receives little to 
no testing and is less secure.


Specifically:

- Support for the force-enable/force-disable prefs has been removed 
completely.
- The browser.tabs.remote.autostart pref being set to false will no 
longer turn off e10s in the following case (ie if **all** of these are 
true):

1. you're running desktop Firefox
2. you're running an 'official' build (MOZ_OFFICIAL build define; 
basically anything other than local builds)
3. you're not running our automated tests (specifically, 
MOZ_DISABLE_NONLOCAL_CONNECTIONS is not set).


The autostart pref will thus continue to turn e10s on/off for any of the 
following):

- non-desktop-Firefox (comm-central, Fennec, ...)
- for automated tests (so --disable-e10s switches in ./mach will 
continue to work as you expect, and tests that always run with e10s off 
will continue to do so)

- on your own, local, non-MOZ_OFFICIAL builds

Longer-term, I'd like to move those cases away from the pref one way or 
another, and remove the pref altogether.


If you need to disable e10s for manual tests on an official build, you 
can use the (pre-existing) MOZ_FORCE_DISABLE_E10S environment variable.


I expect this to be uncontroversial given the long-ish discussion about 
e10s and automated test support in general in m-d-platform prior to this 
happening. If you spot issues with the implementation, please do file 
follow-up bugs.


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


Re: Intent to ship: Visual Viewport API on Android

2019-05-13 Thread James Graham



On 10/05/2019 21:49, David Burns wrote:

Not yet as we are stabilising tests for gecko view but hopefully soon!


That won't automatically work; we'd need to start uploading Android 
results to wpt.fyi. Which is possible in one of two ways:


* Add Geckoview on Android to the TC configuration for wpt
* Start uploading results from m-c

The former has the advantage that all the upstream pushes will run kust 
like for desktop, so the results will be directly comparable with other 
browsers. The problem is that there may be implementation difficulties 
connecting up taskcluster-github with the packet infrastructure for 
running in the Android emulator. However if we do this it seems likely 
we can also make Chrome Android work as a point of comparison.


The alternative where we just publish the results from m-c will end up 
creating an entirely seperate set of Firefox-only data corresponding to 
m-c pushes. That data won't be directly comparable against other 
browsers, so although it's easier to do it's less useful.


I think getting android running upstream would be a good use of time and 
resources, but it's likely to be a reasonable amount of work.

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


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

2019-05-13 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/y4suplk9.

Bugs logged by Desktop Release QA in the last 7 days:

Firefox: Toolbars and Customization
NEW - https://bugzil.la/1550753 - Tab navigation could be improved for 
the menu bar customized Edit controls/Zoom control


Toolkit: XUL Widgets
RESOLVED FIXED - https://bugzil.la/1549931 - The tree column picker menu 
from the Saved Logins dialog box is wrongly displayed if opened twice


Toolkit: Video/Audio Controls
NEW - https://bugzil.la/1550416 - Picture-in-Picture mirrorred in calls 
- personal_screens


mozilla: contain-facebook
NEW - #330  - 
"The tooltip on Yahoo News doesn’t have any text on it"


mozilla: contain-facebook
CLOSED - #331  - 
Multiple badges are displayed on the page


mozilla: contain-facebook
NEW - #332  - On 
Pinterest the badge is duplicated, both the 28px by 28px and the 17px by 
17px are displayed


mozilla: contain-facebook
CLOSED - #333  - 
The badge remains displayed after dismissing the FBC panel


mozilla: contain-facebook
NEW - #334  - On 
yelp there is no badge for Sign up button, but there is one for Log in 
button


mozilla: contain-facebook
NEW - #335  - 
Back button unavailable after accessing the facebook page from 
menshealth.com


mozilla: contain-facebook
NEW - #336  - 
The login with facebook buttons are not actionable on Hi5


mozilla: contain-facebook
NEW - #337  - 
[Intermittent] Container badge appears and disappears after accessing a 
share link or by hovering over it on USPTO


mozilla: contain-facebook
NEW - #340  - On 
premierleague.com the Sign In button doesn't work


mozilla: contain-facebook
NEW - #341  - 
The badge for share buttons is not always displayed for certain websites


mozilla: contain-facebook
NEW - #343  - 
FBC tool-tip appear as cut off on hovering


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


Regards,
Mihai Boldan





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