Intent to ship: XMLHttpRequest parsing errors will yield a null document for web content, not one with a root.

[Thomas Wisniewski]

Summary: XMLHttpRequests for web content (and WebExtensions) will now
follow the spec and return a null response/responseXML in the event of
a parsing error, rather than a document with a  root. The
web console will also log a more informative error. Non-WebExtension
addons and other chrome code will continue to generate 
documents, for backwards compatibility.

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

Standard: https://xhr.spec.whatwg.org/#document-response

Platform coverage: all.

Estimated release: Firefox 50.

Devtools bug: none needed.

Other browsers: Chrome, Safari and Edge already follow the spec behavior.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement version 4 of the Safe Browsing protocol

[Mike Hommey]

On Tue, Aug 02, 2016 at 07:28:32AM -0700, Francois Marier wrote:
> The Safe Browsing service we rely on for protection against malware and
> deceptive sites is migrating to a new version of the Safe Browsing
> protocol. Version 4 will enable Google to quickly send the most relevant
> list entries to clients (based on platform and locale for example) as
> well as deal with false positives in a more efficient way.

I thought Intend to implement messages were "limited" to features
exposed to the web. Not that I'd mind for more Intend to implement, but
then don't we need to better define what they apply to?

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

Usability improvements for Firefox automation initiative - Status update #2

[Armen Zambrano G.]

On this update, we will look at the progress made since our initial update.

A reminder that this quarter’s main focus is on:
* Debugging tests on interactive workers (only Linux on TaskCluster)
* Improve end to end times on Try (Thunder Try project)

For all bugs and priorities you can check out the project management 
page for it:

https://wiki.mozilla.org/EngineeringProductivity/Projects/Debugging_UX_improvements



Debugging tests on interactive workers
---
Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1262260

Accomplished recently:
* Bug 1285582 - Fixed Xvfb startup issue
* Bug 1288827 - Improved mochitest UX (no longer need --appname, paths 
normalized)

* Bug 1289879 - Uses mozharness venv if available

Upcoming:
* Support for smaller test harnesses (Cpp, Mn, wpt, etc)
* Improved one-click-loaner UX

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1285582
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1288827
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1289879



Thunder Try - Improve end to end times on try
-

Project #1 - Artifact builds on automation
##
Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1284882

No news for this edition and probably the next one.


Project #2 - S3 Cloud Compiler Cache

Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1280641

* Working on testing sccache re-write on Try
* More news on following update


Project #3 - Metrics

Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1286856

Accomplished recently:
* Bug 1242017 - Metrics team will configure ingestion point into Telemetry

Upcoming:
* Bug 1258861 - Working on underlying data model at the moment:

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1242017
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1258861

Other
#
* Bug 1287604 - Experiment with different AWS instance types for TC 
linux64 builds
  * Some initial experiments have shown we can shave 20 minutes off an 
average linux64 build by using more powerful AWS instances, with a 
reasonable cost tradeoff. We’ll start the work of migrating to these new 
instances soon.
* Bug 1272083 - Downloading and unzipping should be performed as data is 
received
  * Project for investigation has been started: 
https://github.com/armenzg/download_and_unpack

* Bug 1286336 - Improve interaction of automation with version control
  * Buildbot AMIs now seeded with mozilla-unified repo (Bug 1232442)
  * TaskCluster decision and various lint/test tasks now use `hg 
robustcheckout` and share caches more optimally (Bug 1247168)

* Flake8 tasks now complete in as little as 9s (~3m before)
* Decision tasks now complete in <60s on average
  * Some TaskCluster tasks now share VCS checkouts on Try (Bug 1289643)
* Tasks will complete faster on Try due to not having to perform 
full VCS checkout


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1287604
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1272083
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1247168

--
Zambrano Gasparnian, Armen
Engineering productivity
http://armenzg.blogspot.ca
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: CSS4 :any-link pseudo-class

[Thomas Wisniewski]

As of Firefox 50, I intend to unprefix the CSS4 :any-link pseudo-class
on all platforms. It has been supported in Firefox for a long time now
as :-moz-any-link, and has been aligned with the spec for several
years as well (see
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21070).

Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=843579
Link to standard: https://drafts.csswg.org/selectors-4/#the-any-link-pseudo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

How useful is the WinSock LSP field in crash reports?

[Nicholas Nethercote]

Hi,

Crash reports have a field called "WinSock LSP". In a crash report on
crash-stats.mozilla.org, this field is shown in both the "Details" tab
(which is the most important tab) and the "Metadata" tab (where all raw
crash report fields are always shown).

I suspect it is rare for this field to be useful. (I've never found it
useful.) It is also long, typically dozens of lines, and typically accounts
for a quarter or more of the space taken up by the fields in the "Details"
tab.

I propose removing it from the "Details" tab. It will still be visible in
the "Metadata" tab. Any objections? Am I missing any reason why it is
frequently useful?

Thanks.

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

[Firefox Desktop] Issues found: July 18th to 22nd

[Andrei Vaida]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *July 18 - July 2**2* (week 29).


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


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



*RELEASE CHANNEL**
*none

*BETA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1287843 
	Active download is paused without warning if disconnected from internet 
connection

Firefox
Downloads Panel
YES NOBODY
1287821 
	[Linux] "Copy download link" option available in the downloads panel 
but not in the library view

Firefox Downloads Panel TBD NOBODY
1287823 
	[Linux] Dragging & dropping a download from the downloads panel on 
desktop saves a txt file

Firefox Downloads Panel YES NOBODY
1287836 
Download is "Failed" after reconnecting to a WiFi network that was lost.
Firefox
Downloads Panel TBD NOBODY
1288042 
Bugged display when sharing Hello from Windows to Safari
Hello (Loop)
Client
NO  NOBODY
1288120 
"Switch to tab" still appears after the user closes the initial tab
Firefox
Location Bar
NO  NOBODY
1288712 
Forgot password: can enter another account's email, but it does not 
reset
Cloud Services
Server: Firefox Accounts
TBD NOBODY
1288122 
	Hello conversation is interrupted at the start for 1-2 seconds when 
linux is involved

Hello (Loop)Client  NO  NOBODY
1288721 
sec-sensitive
---
---
YES NOBODY
1288688 
	Empty username on accounts.firefox.com notification panel after 
changing the password

Toolkit
Password Manager
NO  NOBODY
1288729 
Wrong message appears when enabling themes if user is signed into Sync
Firefox
Sync
NO  NOBODY
1288751 
	[Win 10] Scrolling does not work on recent Windows 10 Insider Preview 
Builds

Firefox
General
YES Jim Mathies


*AURORA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1288732 
	Screen sharing is still open in permissions dialog even after disabling 
it on https://web.ciscospark.com

Core
WebRTC
TBD Jan-Ivar Bruaroey


*NIGHTLY CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1287413 
Blank area visible at the bottom of the CSS pane
Firefox
Developer Tools: Inspector
YES Jan Honza Odvarko
1287438 
	While undocked, Dev Tools panel vanishes behind the browser window when 
'Show MDN Docs' option is selected

Firefox Developer Tools: CSS Rules Inspector
YES Julian Descottes
1287780 
	Dotted focus outline around 'Visit MDN page' link is not displayed at a 
first attempt

Firefox Developer Tools: CSS Rules InspectorNO  NOBODY
1287808 
The tab mute/unmute button is not working while RDM is enabled
Firefox
Developer Tools: Responsive Design Mode
YES NOBODY
1288380 
There is no tooltip displayed for the touch event button from RDM
Firefox Developer Tools: Responsive Design Mode NO  
Benoit Chabod
1288409 
	The top part of the RDM modal is unreachable if the Firefox window is 
resized

Firefox
Developer Tools: Responsive Design Mode YES NOBODY
1288752 
	While undocked, Dev tools panel vanishes behind the browser window when 
clicking on 'Visit MDN page'

Firefox Developer Tools: CSS Rules InspectorYES Julian 
Descottes


*ESR 

Re: Intent to implement and ship: Iterable declarations on NodeList and DOMTokenList

[Boris Zbarsky]

On 8/2/16 8:32 AM, masataka.yak...@gmail.com wrote:

It looks like WebKit landed support recently.
https://trac.webkit.org/changeset/203222
https://trac.webkit.org/changeset/203728


Ah, thanks.  I just checked a WebKit nightly, and yes, they support it 
in a way compatible with our implementation (unlike Chrome, which is 
slightly buggy; see 
).


-Boris

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

Re: Intent to implement and ship: Iterable declarations on NodeList and DOMTokenList

[masataka . yakura]

On Saturday, July 30, 2016 at 11:41:23 AM UTC+9, Boris Zbarsky wrote:
> Summary: The idea is to have keys/entries/values/forEach methods on 
> these two interfaces, so you can do things like:
> 
>document.querySelectorAll("whatever").forEach(someFunc)
> 
> and
> 
>document.body.classList.forEach(someFunc)
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1290636
> 
> Standard: https://dom.spec.whatwg.org/#interface-nodelist and 
> https://dom.spec.whatwg.org/#interface-domtokenlist
> 
> Platform coverage: all.
> 
> Estimated release: Firefox 50.
> 
> Devtools bug: none needed.
> 
> Other browsers: Chrome is shipping this in stable; no signals from 
> Safari or Edge.

It looks like WebKit landed support recently. 
https://trac.webkit.org/changeset/203222
https://trac.webkit.org/changeset/203728
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement version 4 of the Safe Browsing protocol

[Francois Marier]

The Safe Browsing service we rely on for protection against malware and
deceptive sites is migrating to a new version of the Safe Browsing
protocol. Version 4 will enable Google to quickly send the most relevant
list entries to clients (based on platform and locale for example) as
well as deal with false positives in a more efficient way.

Meta bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1167038

Implementation plan:
https://wiki.mozilla.org/Security/Safe_Browsing/V4_Implementation

Link to specification:
https://developers.google.com/safe-browsing/v4/update-api

Platform coverage: Desktop and Android


Estimated or target release:

We'll be rolling it out slowly in the pre-release channels and
monitoring it closely via Telemetry before we switch over. We intend to
have the existing V2 code running in parallel with the V4 code for a
little while. Google has agreed to run the old servers until we have
released an ESR which uses the version 4 servers (most likely ESR 59).


Preference behind which this will be implemented:

urlclassifier.phishTable and urlclassifier.malwareTable
https://wiki.mozilla.org/Security/Safe_Browsing/V4_Implementation#Notes


Do other browser engines implement this?

Chromium is working on it. They have landed large parts of it, but it
hasn't shipped to users yet.


Tests:

Our existing tests for version 2 of the protocol will be extended to
support version 4 too. We are also adding V4-specific tests.

https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/url-classifier/tests
https://hg.mozilla.org/mozilla-central/file/tip/testing/firefox-ui/tests/functional/security
https://hg.mozilla.org/mozilla-central/file/tip/browser/components/safebrowsing/content/test
+ manual smoke tests


Security and Privacy concerns:

The privacy characteristics of the new protocol are essentially the same
as the old protocol.
https://support.mozilla.org/en-US/kb/how-does-phishing-and-malware-protection-work#w_what-information-is-sent-to-mozilla-or-its-partners-when-phishing-and-malware-protection-are-enabled


For more information about Safe Browsing, see the wiki:
https://wiki.mozilla.org/Security/Safe_Browsing
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Increased number of e10s related crashes for firefox-ui-tests on mozilla-central and integration branches

[Mike Conley]

Might be unexpected fallout from bug 1261842 which landed on central on
Monday (July 25th). Does that correspond to your timeline of when this
started showing up?

I'm seeing this in the log for at least one of these:

"JavaScript error: chrome://marionette/content/listener.js, line 1017:
NS_ERROR_FAILURE: Component returned failure code: 0x80004005
(NS_ERROR_FAILURE) [nsIWebProgress.removeProgressListener]"

Which sounds related to some of the Marionette changes I made for bug
1261842. I'll continue investigation in bug 1290184.

On 29/07/2016 1:50 AM, Henrik Skupin wrote:
> Hi,
> 
> Over the last couple of days I noticed a spike of crashes specifically
> for our firefox-ui-tests as run on Taskcluster (Linux64, Ubuntu 12.04
> docker image). The crashes are completely related to our e10s jobs.
> There are a lot of different crash signatures, but mostly these are:
> 
> [@ libpthread-2.15.so + 0xbd84]
> [@ libc-2.15.so + 0xe7993]
> 
> https://treeherder.mozilla.org/#/jobs?repo=autoland=firefox%20ui%20e10s
> 
> Does anyone know if there were related changes for e10s which might have
> caused those crashes to appear? I'm afraid that we might have some
> unknown top crashers which would go to aurora by the merge early next week.
> 
> Thanks
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform