Re: How can I save Push-Notifications on a Windows 10 PC

[Matthew N.]

On 2020-12-30 6:18 a.m., Ronald Brauer wrote:

The Push-Notifications of a website are only some seconds on my PC. How can I 
see them some time after I got them?


Once bug 1497425 and its dependencies are fixed then notifications will 
show in the Windows 10 Action Center until Firefox is closed. If any 
developers want to push that over the line it would be greatly appreciated.


Bug 1497425 - Turn on Toast Notification on release channel 
(https://bugzil.la/1497425)


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

`mach test --headless` now supports xpcshell-tests

[Matthew N.]

On the next merge to mozilla-central, the `mach test --headless` command
will no longer give an error on directories containing xpcshell tests
<https://bugzilla.mozilla.org/show_bug.cgi?id=1550518> (along with other
suites already supporting --headless). Prior to this enhancement the
command would fail as soon as an xpcshell test was encountered since that
harness didn't support the argument. This required running mach multiple
times in order to execute all tests for a component. Now you no longer have
to worry about whether the tests you execute have a mix of xpcshell and
mochitest flavors when deciding whether to use --headless.

This also means that `mach xpcshell-test --headless` doesn't error, but
that's probably not too interesting for most developers on its own as the
xpcshell test harness already supported running specific tests in headless
mode with the `headless = true` xpcshell.ini annotation
<https://searchfox.org/mozilla-central/search?q=headless+%3D&case=false®exp=false&path=xpcshell.ini>.
The --headless command line argument has the same behavior as that
annotation
<https://searchfox.org/mozilla-central/rev/4e228dc5f594340d35da7453829ad9f3c3cb8b58/testing/xpcshell/runxpcshelltests.py#686-687>,
it's not a no-op, so it may change some behaviour in tests involving
rendering though those are likely very rare in this suite. Also note that
this configuration isn't run in automation so it's possible some tests will
fail under it but don't without --headless so you may want to run a test
without the argument if you're seeing an unusual failure that doesn't
appear in automation. In that case you could opt the test out of headless
mode with `headless = false` in the manifest.

Thanks to Geoff Brown for the quick review.

Matthew N. (:MattN)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIPermissionManager Permission Isolation by OriginAttributes

[Matthew N.]

On 2019-10-16 7:15 a.m., Paul Zühlcke wrote:

I plan to land a patch next week which will disable OriginAttribute
stripping in the permission manager. This will result in private browsing
windows and containers having isolated permissions.


Are we still planning to strip origin attributes before insertion into 
the permission manager for permissions that have management UI (e.g. in 
about:preferences)? If not, how do we plan to represent the origins 
there? I think we wouldn't want to expose the originSuffix directly to 
our users e.g. something like https://www.facebook.com^userContextId=7 
when using the Facebook container.


Thanks,
Matthew N. (:MattN)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fission Engineering Newsletter #1

[Matthew N.]

On 2019-02-13 9:02 p.m., Tom Ritter wrote:

On Wed, Feb 13, 2019 at 9:48 PM Matthew N.  wrote:

What about doing better sandboxing of the content
process (e.g. ensuring a compromised process can't request information
from the parent that isn't relevant to it)?


This is https://bugzilla.mozilla.org/show_bug.cgi?id=1505832
Its major sub-bug that pertains specifically to IPC is
https://bugzilla.mozilla.org/show_bug.cgi?id=fission-ipc

For now, the focus on Fission is just getting it working, these
efforts (stronger sandboxing) will come after that.


I quoted the part about the milestone flag as I was wondering whether we 
are supposed to nominate such bugs now or we should only be nominating 
functional bugs? (Same goes for memory usage ones.)

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

Re: Fission Engineering Newsletter #1

[Matthew N.]

On 2019-02-04 6:02 a.m., Nika Layzell wrote:

If have a bug which may be relevant to fission,*please*  let us know by
setting
the “Fission Milestone” project flag to ‘?’. We’ll swing by and triage it
into
the correct milestone.


It seems to me like there are a few overlapping areas in progress that 
are related but I'm not sure if they are now being tracked under one 
Fission umbrella… What types of bugs are considered part of the Fission 
project? Are you including bugs that are about reducing our memory usage 
with more processes? What about doing better sandboxing of the content 
process (e.g. ensuring a compromised process can't request information 
from the parent that isn't relevant to it)?


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

Re: Coming in Firefox 65: Dedicated Profiles Per Install and Profile Downgrade Protection

[Matthew N.]

Our current Firefox migrator (used for a Firefox Refresh) just copies files
so wouldn't be suitable for a downgrade scenario as it could introduce
problems that we're trying to avoid with this approach. We could rewrite it
to be more like other migrators where it would read individual records from
the old profile and then insert them into the new file/DB but that would be
a fair amount of work.

For the case of testing a newer version like you mentioned (going from
Release to Beta or Nightly), copying the files should be safe and so you
could use the `-migration` command line option to migrate from the old
profile to the new one. There is no UI for this so you'd want to provide a
.bat file for the user to run your testing Firefox build with the command
line argument. We've done similar things for user testing
 before.

Cheers,
Matthew

On Tue, Oct 23, 2018 at 8:34 AM, Michael Verdi  wrote:

> Dave could there be a way/option to migrate safe data to the new profile
> similar to what we do with a refresh?
>
> On Thu, Oct 18, 2018 at 2:32 PM Dave Townsend 
> wrote:
>
>> In Firefox 65 we intend to ship two new features to help prevent user
>> frustration caused by using profiles created by newer versions of Firefox.
>>
>> Why
>>
>> Firefox stores all of its settings in the user’s profile and unless
>> certain command line arguments are used Firefox always launches with the
>> same profile. Periodically as Firefox upgrades it makes changes to the
>> settings that can render the profile unusable by earlier versions of
>> Firefox. This can cause anything from certain features of Firefox being
>> broken after a downgrade to Firefox crashing on startup.
>>
>> To protect against this two new features will be landing in Nightly soon.
>>
>> Dedicated Profiles Per Install
>>
>> A common cause of users switching between different versions of Firefox
>> is having Firefox installed multiple times. This most often happens when
>> users have different channels installed at the same time like ESR and
>> Release. It is a common request to be able to run the different installs at
>> the same time. In Firefox 35 this was made possible for the developer
>> edition by giving it a dedicated profile. The new dedicated profiles per
>> install feature extends this and will give every install of Firefox on the
>> computer a dedicated profile by default.
>>
>> Users will be able to run different installs of Firefox simultaneously.
>> Each will use a different profile for its settings. Upgrading an install of
>> Firefox will keep it using the same settings.
>>
>> We’re tracking work on this feature in bug 1474285.
>>
>> Profile Downgrade Protection
>>
>> For cases where users manually downgrade an install of Firefox or attempt
>> to forcefully use an older version of Firefox with a newer profile the
>> profile downgrade protection feature will now tell the user that the
>> profile is too new to use with this Firefox giving them the option to
>> create a new profile to use or to quit.
>>
>> We’re tracking work on this feature in bug 1455707.
>>
>> Developer Implications
>>
>> As developers it is quite common to switch between different builds for
>> example when testing different built versions of Firefox and doing
>> regression testing. To support these use-cases a new command line argument
>> “--allow-downgrade” will allow skipping the downgrade protection.
>>
>> Conclusions
>>
>> While some users may be impacted by this change we believe that most
>> users will be unaffected and those that are will see less problems caused
>> by downgrades than previously. This will give us the ability to ignore the
>> possibility of downgrades when implementing new features and fixing bugs
>> going forwards. Being able to make the assumption that this code works as
>> designed will allow us flexibility in other changes downstream.
>> ___
>> firefox-dev mailing list
>> firefox-...@mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>
>
> --
> Michael Verdi • Firefox Search UX • Slack: verdi
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Avoid Visual Studio 2017 15.7.0

[Matthew N.]

On 2018-05-08 6:40 a.m., Ryan VanderMeulen wrote:

Yesterday, Microsoft released Visual Studio 2017 15.7.0. Unfortunately, it
is currently not usable for building Firefox due to bug 1458247 (internal
compiler errors in WebRTC code). The bug was already reported and confirmed
upstream during the 15.7 preview cycle, but unfortunately the final release
still shipped with the bug present.

At this point, there are no workarounds available for this issue, so avoid
the update if you want to be able to continue building Firefox.


If you need to update to 15.6 but hadn't yet, you can download old 
versions at 
https://docs.microsoft.com/en-us/visualstudio/productinfo/installing-an-earlier-release-of-vs2017


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

Re: Refactoring proposal for the observer service

[Matthew N.]

On 2018-01-04 10:00 AM, Nathan Froyd wrote:
…

2) How would one shoehorn this into *DL?  The options that come to mind are:

- Separate methods for every observer topic, which sounds terrible
from a code duplication perspective.  Though maybe this would be nice
for JS clients, so we could say things like:

   Services.obs.notifyXPCOMShutdown(...)

which would save on some xpconnect traffic and representing a
large-ish enum in JS?
- WebIDL enums (I think), which would carry a large space penalty and
make everything that wants to use the observer service depend on code
from dom/, which seems undesirable.
- IDL enums, which aren't reflected into JS, so we'd need some custom
work there.


As Ben said, XPIDL const's on an interface seem like a missing option 
that would work with JS. Random example: 
https://dxr.mozilla.org/mozilla-central/search?q=RECOVER_SESSION&redirect=false



- IPDL doesn't even have the concept of definable enums, and wouldn't
reflect things into JS, so we'd need even more work there.  (Some of
this may be desirable; we talked about extending IPDL bits into JS in
Austin, and kmaglione felt this was reasonable, so...)

The first and third don't sound *too* bad, but I don't think that
writing a one-off code generator would be strictly worse...


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

Intent to Implement and Ship: HTMLTextAreaElement.autocomplete

[Matthew N.]

*Summary*:
Allows web developers to get the effective/normalized value of the
autocomplete attribute in the same way they currently can for  and
.​

Example:  returns "on" for
textarea.autocomplete.
The return value will respect the pref dom.forms.autocomplete.formautofill,
like we already do for  and  meaning it will only return
"on"/"off" if Form Autofill isn't available to support the other values.

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1020698
*Link to standard*:
https://html.spec.whatwg.org/#the-textarea-element:attr-fe-autocomplete
*Platform coverage*: All but iOS
*Estimated or target release*: Firefox 59
*Preference behind which this will be implemented*: None (it's simply
exposing shared logic for  and  on 
*Is this feature enabled by default in sandboxed iframes*
​:​
Yes
*DevTools bug*: N/A since it's just a
​fairly basic DOM property. In theory devtools could use the internal
getAutocompleteInfo API to show the browsers' interpretation of the parsed
attribute.
*Do other browser engines implement this*
​:​
According to https://wpt.fyi/html/dom/interfaces.html's
"HTMLTextAreaElement interface: attribute autocomplete" row:
* Safari: Shipped <https://bugs.webkit.org/show_bug.cgi?id=150731>
​ in unknown version <https://bugs.webkit.org/show_bug.cgi?id=150731>
* Chrome: N
​ot yet
<https://bugs.chromium.org/p/chromium/issues/detail?id=758074>
​​
​ <https://bugs.chromium.org/p/chromium/issues/detail?id=758074>, but​
​i​
nten
​ding​
to
​i​
mplement and
​s​
hip
<https://groups.google.com/a/chromium.org/d/topic/blink-dev/2tutRHmhwTE/discussion>
* Edge: No
*Tests -*
*​*
* Is this feature fully tested by web-platform-tests*
​:​
​ https://wpt.fyi/html/dom/interfaces.html has basic interface tests and ​
https://wpt.fyi/html/semantics/forms/the-form-element/form-autocomplete.html
tests the common parsing logic (not specific to )

​Thanks,
Matthew N. (:MattN)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: We need better canaries for JS code

[Matthew N.]

Hi David,

On 2017-10-18 1:28 AM, David Teller wrote:

If I understand correctly, this triggered the usual
"undefined is not a function", which was

1/ uncaught during testing, as these things often are;


That's only because this code doesn't have any tests. That was filed as 
bug 1409913.



2/ basically impossible to diagnose in the wild, because there was no
error message of any kind.


There was an error message[2] which clearly pointed to the problem:
"JavaScript error: resource:///modules/CustomizableUI.jsm, line 461: 
TypeError: placements.spice is not a function"



I remember that we had bugs of this kind lurking for years in our
codebase, in code that was triggered daily and that everybody believed
to be tested.

I'd like to think that there is a better way to handle these bugs,
without waiting for them to explode in our user's face. Opening this
thread to see if we can find a way to somehow "solve" these bugs, either
by making them impossible, or by making them much easier to solve.

I have one proposal. Could we change the behavior of the JS VM as follows?

- The changes affect only Nightly.
- The changes affect only mozilla chrome code (including system add-ons
but not user add-ons or test code).
- Any programmer error (e.g. SyntaxError) causes a crash a crash that
displays (and attaches to the CrashReporter) both the JS stack in and
the native stack.
- Any SyntaxError is a programmer error.
- Any TypeError is a programmer error.

I expect that this will find a number of lurking errorsy, so we may want
to migrate code progressively, using a directive, say "use strict
moz-platform" and static analysis to help encourage using this directive.

What do you think?


I'm not really sure that changing the failure mode from a totally broken 
Firefox window to a crash really helps much. Both would have only 
happened once the builds were in the hands of users. The root cause of 
the issue was that there were no automated tests for the relevant code 
and from my understanding we don't need JS VM changes to address that.


I do agree with other messages in the thread about making our test 
harnesses stricter regarding uncaught errors but without this code being 
tested that wouldn't have helped here.



Cheers,
  David



[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1407351#c28


[2] https://bug1409395.bmoattachments.org/attachment.cgi?id=8919310
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Easier debugging/inspecting of remote tab state with the Browser Content Toolbox

[Matthew N.]

On 2017-10-03 5:44 PM, Boris Zbarsky wrote:

On 10/3/17 7:15 PM, Matthew N. wrote:
For those of you who don't know, when the "devtools.chrome.enabled" 
pref is
true the Web Developer > Browser Content Toolbox opens a toolbox 
targeting

the content process that the selected tab is loaded in.


Matt,

Do you know whether this starts a new Firefox instance, like the Browser 
Toolbox?


I don't believe it does since the the Browser Content Toolbox opens as a 
window in the regular chrome UI process.


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

Easier debugging/inspecting of remote tab state with the Browser Content Toolbox

[Matthew N.]

With bug 1401343 
fixed, `TabChildGlobal`s for the attached content process are exposed via a
`tabs` getter in the Browser Content Toolbox's console tab. This makes it
much easier to inspect a remote tab's state or to access privileged APIs
related to remote tab content. The motivation for this change is to make it
less tedious to inspect remote tab state with e10s, especially without
add-on shims/CPOWs.

For those of you who don't know, when the "devtools.chrome.enabled" pref is
true the Web Developer > Browser Content Toolbox opens a toolbox targeting
the content process that the selected tab is loaded in. From there you can
access `tabs` in the Console tab to get an array of the `TabChildGlobal`s
(which have access to the content Window object via `content`).

Examples:
1) Access a ChromeOnly property on an element: `tabs[0].content.document.
querySelector("#myEl").nodePrincipal`
2) Add an event listener to a tab child:
`tabs[3].addEventListener("change", tabs[3].console.log)`

Bug 1346316  tracks
giving easier access to the selected tab's TabChildGlobal and making the
frame picker work (to more easily change between `TabChildGlobal`s by URL).

Happy debugging!
Matthew Noorenberghe (:MattN)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Requesting specific talos jobs in try syntax is broken on TC

[Matthew N.]

On 5/13/17 11:31 AM, Dustin Mitchell wrote:

Specifically, -t for e10s talos doesn't work.  Non-e10s talos works
fine (but then, e10s talos are the interesting perf numbers..)


That doesn't match my experience unless simply including an e10s talos 
job in the syntax also breaks the non-e10s ones.



From the look of it, this has been broken since mid-March, but was

only recently reported.  Note that issues like this are now fixable by
anyone who can write a patch, since they are defined in the source.
Sure, there's a bit of domain knowledge required, but it's just
(nicely commented, documented) code!


The problem I'm seeing only started in the last week or so.


Dustin

2017-05-13 14:15 GMT-04:00 Matthew N. :

See https://bugzilla.mozilla.org/show_bug.cgi?id=1363409 for details. It
will still work on Win7 which uses buildbot, but won't on OS X or Linux
which use Taskcluster (TC).

The workaround is to request all talos jobs with `-t all`.


Btw. I just tried this workaround and it also didn't give me any TC jobs 
but some other jobs did get them so it seems like there is another 
problem which is being discussed in #taskcluster.



I'm just passing along the info to save others time

Thanks,
Matthew N. (:MattN)

P.S. --rebuild-talos was also broken for a while but should now work again
(bug 1317189)
___
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

PSA: Requesting specific talos jobs in try syntax is broken on TC

[Matthew N.]

See https://bugzilla.mozilla.org/show_bug.cgi?id=1363409 for details. It 
will still work on Win7 which uses buildbot, but won't on OS X or Linux 
which use Taskcluster (TC).


The workaround is to request all talos jobs with `-t all`.

I'm just passing along the info to save others time

Thanks,
Matthew N. (:MattN)

P.S. --rebuild-talos was also broken for a while but should now work 
again (bug 1317189)

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

Re: Heads Up: /storage upgraded from version 1.0 to 2.0

[Matthew N.]

On 2017-03-07 7:09 PM, Mike Hommey wrote:

While talking about this... I think it's about time we had an actual
plan for data cleanup.

Last week, when the cloudflare thing happened, I went through the files
in my profile looking for all my password-manager-managed passwords and
the domains associated with them. They used to be in a sqlite db, and
are now in json.

The change happened 3 years ago, in Firefox 32.

Guess what? the sqlite db is still there in my profile, with old, stale,
data in it.


I'm not sure why you're using this as an example of a need for a "plan 
for data cleanup": I don't see this as a general problem and it 
shouldn't be causing you harm. A bug was filed for that 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1013947) which is the 
usual behaviour so it's not like we forgot about this. We intentionally 
gave a grace period to give people time to downgrade if necessary. The 
problem is that password manager hasn't been getting properly resourced 
other than a bit in the first half of 2015 and this bug is not 
considered a priority since like I said above it doesn't cause harm, 
it's a small file and that old file is using the same encryption as the 
new file. If you disagree about the priority then feel free to comment 
in the bug or find an assignee.


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

Re: Deprecating XUL in new UI

[Matthew N.]

Trees are the big thing that come to mind. I've heard about three non-XUL
re-implementations (IIRC mostly in devtools) which sounds like a
maintainability issue and potentially redundancy. I would rather keep using
XUL trees than have even more different tree implementations (though I'd be
fine with a one or two simpler replacements since many uses of a xul:tree
don't need a lot of the feature like nesting) which brings me to my next
point:

What about XBL? Does it just work from XHTML documents? Is our
implementation of Web Components ready to replace it and riding the trains?
I think it would be good to implement drop-in replacements (or as close as
possible) for some simple XBL bindings or native XUL elements to prove that
Web Components are a replacement. Once the Web Component version is working
we can transition to it everywhere. Perhaps something like 
would be a good candidate.

Matthew

On Mon, Jan 16, 2017 at 12:43 PM, Dave Townsend 
wrote:

> One of the things I've been investigating since moving back to the desktop
> team is how we can remove XUL from the application as much as possible. The
> benefits for doing this are varied, some obvious examples:
>
> * XUL is a proprietary standard and we barely maintain it.
> * Shallower learning curve for new contributors who may already know and
> use HTML.
> * HTML rendering is more optimized in the platform than XUL.
> * Further integration of Servo code may require dropping XUL altogether.
>
> The necessary first step of reducing XUL use is to stop adding any more UI
> that uses XUL and here I'm talking about wholly new UI, additions to
> browser.xul and other existing UI are a separate concern. What do folks
> think about making this a rule for new projects in the near future?
>
> Of course there are some features missing from HTML that make this
> impossible in some cases right now. Some that I've already found:
>
> * HTML has no support for popup panels like XUL does. The devtools team
> have been working around this but they are still dependent on XUL right now.
> * iframe elements don't have the same capabilities that the XUL browser
> element does and we use that in some UI.
> * Top level menus on OSX are currently only able to be defined with XUL
> elements. This only affects UI that uses top-level windows and most of our
> new UI is in-content so may be less of an issue.
>
> What other features do we depend on in XUL that I haven't listed?
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to restrict to secure contexts: navigator.geolocation

[Matthew N.]

On Wed, Oct 26, 2016 at 4:26 PM, Jan-Ivar Bruaroey  wrote:

> On 10/26/16 6:28 PM, Matthew N. wrote:
>
>> On 2016-10-26 1:40 PM, Jan-Ivar Bruaroey wrote:
>>
>>> At the risk of sounding pragmatic/opportunistic, why not wait until the
>>> usage numbers go down, as they're bound to?
>>>
>>
>> And in the meantime we could remove the "always allow" option for
>> geolocation over HTTP like we do for another permission (WebRTC IIRC).
>>
>> Matthew
>>
>
> Good point. Mind filing a bug if there isn't one already?
>

​I filed ​
https://bugzilla.mozilla.org/show_bug.cgi?id=1313242
​​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to restrict to secure contexts: navigator.geolocation

[Matthew N.]

On 2016-10-26 1:40 PM, Jan-Ivar Bruaroey wrote:

At the risk of sounding pragmatic/opportunistic, why not wait until the
usage numbers go down, as they're bound to?


And in the meantime we could remove the "always allow" option for 
geolocation over HTTP like we do for another permission (WebRTC IIRC).


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

Re: Reorganization of Firefox-UI tests in mozilla-central

[Matthew N.]

On 2016-09-02 2:29 AM, Gijs Kruitbosch wrote:

On 02/09/2016 00:15, Matthew N. wrote:

On 2016-09-01 9:24 AM, Gijs Kruitbosch wrote:

On 01/09/2016 16:37, Henrik Skupin wrote:

Do those locations sound good? I have heard at least once that
"firefox_ui" might not be the best choice as folder name, but that's
how
the harness is called, and corresponds to what we have for other
harnesses too.


As I did over IRC, I would like to strongly object to the continued use
of per-test-type subfolders in our test directories. You can already use
a specific mach command per test type, and the tests are listed in
different manifests, *and* there's all the different filename
conventions (browser_, test_html, test_xul, .js) that
further point out what type of test you're looking at. The subfolders
add nothing useful.


As someone who has been adding the directory levels to
toolkit/components/passwordmgr/test/ recently, I disagree with this
since they add a grouping of relevant files making it more obvious which
files go with which test suites.


But in general you don't need to know this? When does it matter and is
it an unknown? You can just pass a filename to ./mach test and it'll do
the right thing.


* refactoring tests and related helper functions (e.g. for e10s). e.g. 
pwmgr_common.js or notification_common.js could belong to any of the 
four suites used by pwmgr. Same for a head.js file.
* when working on a test and the directory doesn't take a super long 
time to run I often want to run everything in the directory for the 
suite of the I'm working on, especially as I'm putting the final touches 
on the test. This is mostly to make sure I'm doing proper cleanup in the 
test.
* knowing which of the ini files to add a new test to (and actually 
noticing the ini files if there are lots of files in the directory).
* when writing a new test I want to look at what helpers relevant to the 
component are available for that suite



* Chrome mochitests, plain mochitests and xpcshell share the same prefix
(test_) so they are interleaved together in directory listings.


Again, not sure why that's a problem. If there's too many files in a
directory, that's a problem, but I'd rather we split them out by
function/subject than by test suite.


See above


* Files that accompany tests have no prefix convention.


Yes, but if that is a problem (which I'm not sure about) it continues to
be a problem when you don't mix test types into one directory.


If you're not mixing then you know that accompanying files are relevant 
to the tests in that directory.



* head.js files have no indication of what suite they're for (i.e. no
prefix)


But there's no need for the files to be called head.js. All of this is
also already true without adding the firefox-ui tests.


Right (for xpcshell) but that's the standard name that is commonly used, 
second is to have head_(name of thing being tested).js which would still 
conflict with another head_(name of thing being tested).js for a 
different suite in the same directory if they're testing the same 
module/component.



* `mach test` doesn't support specifying a flavor of mochitest.


I'm sure that could be added (in fact, I thought there were plans for
this already) - in the meantime, ./mach mochitest works.


I would really like this but it's still a reason to not flatten test 
directories at the moment.



* Changing the subdirectory of my `mach mochitest` command is usually
faster than adding the flavor argument since the path is usually at the
end of the command. Since `mach test` doesn't support the flavor
argument I don't have to remember whether to use the argument or change
the path as I can always change the path when directories are used.


Again, we should just fix ./mach test. But also, this isn't just about
the mach command, but also about editing, and running individual tests,
where the subdirectory "system" forces me to do useless extra typing to
run/edit "browser/browser_foo.js". It gets even worse when you write a
new test and realize halfway through that you need to switch from
mochitest-plain to mochitest-browser because mochitest-plain doesn't
have enough privileges to determine whatever you need to determine.


In the rare cases where you need to move a test between suites I don't 
see this a big deal.



Out of curiosity: if you're not running a single test, why isn't just
running all the mochitests sufficient? Why are you wanting to run a
specific suite but not the others? And is that really the majority case?


My most common experience is with password manager which uses three 
flavors of mochitest (it really should only need 2 but the last "chrome" 
test hasn't been rewritten yet). When I'm developing a new test which 
may involve refactoring shared suite help

Re: Reorganization of Firefox-UI tests in mozilla-central

[Matthew N.]

 about IMO and I think naming the suite 
"Firefox-UI" was confusing from the beginning. If I was a new 
contributor working on a UI feature and decided I wanted to write tests, 
I wouldn't want to be misled into thinking I should write a "Firefox-UI" 
test when mochitest-browser-chrome is actually the desired suite. I 
would suggest "puppeteer" or "marionette" for directory names to avoid 
confusion.


Thanks,
Matthew N. (:MattN)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Mercurial performance (vs git)

[Matthew N.]

Make sure you have enabled the fsmonitor[1] extension for mercurial if 
your prompt is using `hg` commands. I believe `mach mercurial-setup` now 
helps with this.


Matthew N. (:MattN)

[1] https://www.mercurial-scm.org/wiki/FsMonitorExtension

On 2016-08-15 12:46 PM, Botond Ballo wrote:

Cross-posting to dev-version-control

On Mon, Aug 15, 2016 at 3:39 PM,   wrote:

For the last few months I've been mostly using git clone of mozilla-central 
because I'm used to git. Now I'm trying to set up my mercurial environment to 
match what I have for git in order to reduce the bias toward the latter.

One of the crucial parts of my workflow is the git completion shell prompt that 
gives me information about branch I'm on and untracked/modified files.

This is how my shell prompt looks like on gecko-dev (git clone):

zbraniecki@cintra:~/projects/mozilla/gecko-dev (master %=)$

and if I modify any file it may look like this:

zbraniecki@cintra:~/projects/mozilla/gecko-dev (master +%>)$

I tried to get something similar for HG, including hg-prompt (written in 
python), and vcsprompt (written in C), but both are painfully slow.

What's striking, on the same repo, the git is 3 times faster than hg to get me 
the prompt shell.

zbraniecki@cintra:~/projects/mozilla/gecko-dev (master %=)$ time vcprompt -f "( %b 
%u%%%m)"
( master ?%)
real0m0.472s
user0m0.236s
sys 0m0.384s

vs

zbraniecki@cintra:~/projects/mozilla/mozilla-central$ time vcprompt -f "( %b 
%u%%%m)"
( default %+)
real0m1.643s
user0m1.224s
sys 0m0.396s


I thought that maybe it's just vcprompt, so I tried status:

zbraniecki@cintra:~/projects/mozilla/mozilla-central$ time hg status

real0m1.706s
user0m1.380s
sys 0m0.316s

vs.

zbraniecki@cintra:~/projects/mozilla/gecko-dev (master %=)$ time git status
On branch master
Your branch is up-to-date with 'origin/master'.

real0m0.399s
user0m0.204s
sys 0m0.332s

If I understand correctly our choice of using mercurial over git was driven by 
the performance. Am I doing something wrong?

It seems like the performance difference is quite substantial.

zb.
___
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: MXR permanently offline, please transition to DXR

[Matthew N.]

On Fri, Jul 8, 2016 at 12:27 PM, Lawrence Mandel 
wrote:

> We do in the case of 3rd party software referencing files from MXR (and
> I'm told there is a lot of this).
>

​That's an existing problem which is orthogonal to the MXR decommissioning
so that doesn't need to be solved now or block better solutions to the
problem at hand.

IMO we should redirect mxr.mozilla.org + lxr.mozilla.org to ​dxr.mozilla.org's
server and have some rewrite rules to fix the cases where the URL needs to
change to retrieve the equivalent content.

​Rewriting inbound links is addressing the problem at the wrong place IMO
since there are so many links you won't be able to fix and there's not a
good reason to break them.


> We also can't guarantee that MXR URLs will direct to the right place in
> DXR. There is likely a balance to be struck here with highly referenced
> files from 3rd party software getting an interstitial page and other files
> not getting the page. Let's start with getting the page with the redirect
> in place and then iterate from there as required.
>
> Lawrence
>
>
> On Fri, Jul 8, 2016 at 3:24 PM, Bobby Holley 
> wrote:
>
>> Can we skip the interstitial page and make the notice (if any) more
>> unobtrusive somehow? There are tons of mxr links all over the place, and
>> many of them are immutable. We don't gain anything by informing the viewer
>> about their obsolescence instead of showing them the content they want.
>>
>> On Fri, Jul 8, 2016 at 12:20 PM, Lawrence Mandel 
>> wrote:
>>
>>> dev-platform was not included on my response below. Looping back in to
>>> this
>>> fork of the thread.
>>>
>>> On Fri, Jul 8, 2016 at 10:55 AM, Lawrence Mandel 
>>> wrote:
>>>
>>> > Sorry Dao. I have seen some responses. Maybe they were off list. We're
>>> > working on details now. I'm going to get someone to put the redirects
>>> in
>>> > place, likely with an interstitial page advising that MXR has been
>>> > decommissioned, by next week.
>>> >
>>> > Lawrence
>>> >
>>> >
>>> > On Friday, 8 July 2016, Dão Gottwald  wrote:
>>> >
>>> >> Why has nobody responded to the requests for a short-term fix for MXR
>>> >> URLs for more than a week? Are the people responsible for MXR not in
>>> this
>>> >> list?
>>> >>
>>> >> 2016-07-07 18:23 GMT+02:00 Eric Shepherd :
>>> >>
>>> >>> We have tons of mxr links all through MDN, fwiw. I am updating the
>>> >>> macros that generate them, but odds are very good these links will be
>>> >>> around for a good while.
>>> >>>
>>> >>>
>>> >>> That would be perfectly fine for my purposes, I expect, as long as it
>>> >>> dealt with the relevant mxr features.  What I want is for links to
>>> possibly
>>> >>> specific lines of possibly specific revisions of specific files to
>>> work.
>>> >>> Ideally with the highlighting bits too.
>>> >>>
>>> >>>
>>> >>> --
>>> >>>
>>> >>> Eric Shepherd
>>> >>> Senior Technical Writer
>>> >>> Mozilla Developer Network 
>>> >>> Blog: https://www.bitstampede.com/
>>> >>> Twitter: http://twitter.com/sheppy
>>> >>> Doodle: http://doodle.com/the.sheppy
>>> >>>
>>> >>>
>>> >>> ___
>>> >>> firefox-dev mailing list
>>> >>> firefox-...@mozilla.org
>>> >>> https://mail.mozilla.org/listinfo/firefox-dev
>>> >>>
>>> >>>
>>> >>
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
>>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Searchfox (new code search tool)

[Matthew N.]

It's more due to lack of mxr-parity rather than usage that is delaying the
MXR retirement. See the dependency tree:
https://bugzilla.mozilla.org/showdependencytree.cgi?id=1097091&hide_resolved=1

Matthew

On Mon, Jun 6, 2016 at 11:23 PM, Sebastian Zartner <
sebastianzart...@gmail.com> wrote:

> On 7 June 2016 at 07:18, Mike Hommey  wrote:
> > MXR is already taking too long to fade out of existence, do we really
> > want yet another different tool?
>
> For some contributors (like me) this may be, because they simply don't
> know that DXR is meant to replace MXR. If you want people to use DXR,
> you should mention that on the MXR homepage and other places.
>
> Sebastian
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

pushPrefEnv/popPrefEnv/flushPrefEnv now return Promises

[Matthew N.]

Hello,

One of the reasons developers have been avoiding pushPrefEnv compared to 
the synchronous set*Pref (with a registerCleanupFunction) is because 
pushPrefEnv required using a callback function to wait for the 
preference change before moving on in the test file. This can make the 
test flow more complicated (especially when using add_task) and 
therefore harder to follow.


Bug 1197310[1] made pushPrefEnv/popPrefEnv/flushPrefEnv return a promise 
which resolves when the callbacks would have been called so now you can 
simply write test code like so:


add_task(function* setup() {
  yield SpecialPowers.pushPrefEnv({"set": [["signon.debug", true]]});
  …
})

As a reminder, the nice thing about pushPrefEnv is that the pref changes 
are reverted at the end of the test file which avoids them leaking into 
other tests unintentionally.


There are various places in the tree which wrote their own Promise 
wrappers for pushPrefEnv so feel free to file follow-up bugs blocking 
bug 1197310 to remove them.


Cheers,
Matthew N. (:MattN)

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1197310

P.S. For those of you who didn't hear (since there was no announcement), 
you can use add_task in mochitest-plain and mochitest-chrome thanks to 
bug 1187701 if you load …/tests/SimpleTest/SpawnTask.js.

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

Re: Intent to implement and ship: DOMTokenList.prototype.supports

[Matthew N.]

On 2016-05-03 9:01 PM, Boris Zbarsky wrote:

Looking at this code, there's also similar handling for "search", right?
 Again, not sure whether that's exposed in the default UI.


A green plus sign appears above the magnifying glass in the search bar 
for rel="search" and the menu allows you to add that engine to the 
browser. You can test in a new profile with https://bugzilla.mozilla.org/


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

Re: Changes to bugzilla "plugins" product

[Matthew N.]

On Mon, May 2, 2016 at 3:43 PM, Emma Humphries  wrote:

> Andrew, can you do a pass over the bugs since Jan 1st and, and let's
> rename this FFx::Add Ons Compatablity so that it's clear it's not plugins.
>

​Extensions and plugins are both types of add-ons​ so renaming makes it
less clear as it then includes plugins and themes.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Matthew N.]

On 2016-04-18 7:59 AM, Richard Barnes wrote:

Could we just disable HTTP auth for connections not protected with TLS?  At
least Basic auth is manifestly insecure over an insecure transport.  I
don't have any usage statistics, but I suspect it's pretty low compared to
form-based auth.


I also don't have data but I suspect that would break a lot of intranet 
sites where I believe HTTP auth is more common. I think we need to be 
even more careful about compat issues like this since it totally 
prevents you from accessing the service instead of having a somewhat 
broken experience. It seems like something we would want to announce far 
in advance and I suspect there will still be too many affected sites 
even with a years notice. Starting with warnings could help to reduce 
the compat issue down the road if we decide to stop support as not 
everyone will here about our deprecation plans.


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

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Matthew N.]

On 2016-04-15 7:47 AM, Tantek Çelik wrote:

What steps can we take in this direction WITHOUT breaking web compat?


E.g. since one of the issues raised is that *every* time a user
enters/submits a password over HTTP (not secure), it opens them to
being sniffed etc., thus it's good to discourage the frequency.

Some STRAW PROPOSALS that I expect others here (and UX folks) to
easily improve on:

1. Warning (perhaps similar to the invalid red glow) on password
inputs in forms with HTTP "action"


We are making progress towards this and Aislinn Grigas from UX worked on 
a design for something like this: 
https://bugzilla.mozilla.org/attachment.cgi?id=8678150


We already started developer-specific warnings in the web console and in 
the address bar of Nightly + Developer Edition: 
https://hacks.mozilla.org/2016/01/login-forms-over-https-please/


There are some dependencies to fix before doing user-facing warnings 
which we're currently working on. You can follow along in the bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1217162



2. Warning (similarly) on HTTP-auth password dialogs


This is https://bugzilla.mozilla.org/show_bug.cgi?id=1185145 which I 
haven't seen a design for yet but should be less risky to implement than 
for . It is in the Firefox privacy/security team backlog.


Meta bug related to dealing with insecure login forms: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1217142


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

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Matthew N.]

On 2016-03-18 7:22 AM, Mike West wrote:

On Thu, Mar 17, 2016 at 10:04 PM, Justin Dolske  wrote:


On 3/14/16 3:01 PM, Martin Thomson wrote:

The actual benefit is something that is only realized once a site puts

in the effort required.  That is small, yes, but we're seeing sites
actively avoid password managers, hence the aggressive heuristics, and
rAC is much more likely to work for that, since it's implemented and
deployed already.



This is the key issue, IMO, which makes me not interested in having
Firefox implement this API.



My understanding of the objections Martin and Matt have outlined are that
they're not interested in _this spelling_ of the API, and would prefer that
it be spelled using `requestAutocomplete`.



Far too many sites either simply don't care about user password management
(ie, they do problematic things that could easily be fixed), or actively
take steps to intentionally break password managers. In the past we
considered this an advocacy/evangelism problem, and it was deemed the
site's responsibility to play nice. That's worked poorly, and sucks for
users. We now believe that we have to assume a adversarial environment:
it's our job to serve as the user's agent and do whatever it takes to work
on a site.



Sure. Heuristics should continue to work, and I agree 100% that they should
be aggressive enough to trigger on sites that are actively disinterested in
allowing password managers. I don't see that as being at odds with allowing
a site to explicitly integrate with the user's password manager if they
decide to do so.

With the explicit understanding that I don't work at Mozilla, and that
y'all's prioritization is very much yours to set, this sounds like a good
argument for investing effort in those heuristics. It doesn't sound like an
argument against accepting the contribution that Axel is offering.


Coupled with what Justin and Martin said above about adoption (which I 
also expressed), I don't see how it makes sense for us to add more 
complexity to that system. If this was a replacement or alternative to 
the heuristics (like it would be if built on rAc) then it makes more 
sense (rAc is mostly independent of the password manager heuristics) to 
pursue but that's not how I see the interaction with the current spec 
and password manager.



If there's interest in assisting sites that want to play nice, I think it
would be better to start with documenting a set of cross-browser "best
practices" that they can follow, for the standards and implementations that
exist today.



I agree that we should do this regardless.
https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands
exists, for instance, and I'm sure Mozilla has a similar page somewhere.
Perhaps it would be worthwhile to collaborate on something more visible?


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

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Matthew N.]

On 2016-03-14 2:29 AM, Mike West wrote:

On Thu, Mar 10, 2016 at 9:07 PM, Ben Kelly  wrote:
I believe Matthew Noorenberghe had some concerns about the necessity of the

API given requestAutocomplete:


https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/7ouLjWzcjb0/s7aZHGnlAwAJ
  https://github.com/w3c/webappsec-credential-management/issues/2

We should probably come to some consensus there before moving forward.



I agree with MattN that a rAc-style API is a reasonably good fit for
signing up for a new account on a website*. Sign-up forms often encompass a
variety of kinds of information, and layering something on top of existing
forms and autocomplete attributes sounds like a way of providing all of
those bits and pieces at once, rather than having 15 calls to a APIs that
hand them out piecemeal.


Given that, do you think it makes sense to have a separate API for login 
when there is overlap with rAc as well?



With some caveats around XSS protection, I think that rAc could work for
signing-in with passwords. I guess it could work for signing in with
federations, though I think it starts to break down pretty rapidly. I don't
think it would work for any other potential uses of the API. `store()`, in
particular, is more or less the opposite of rAc and seems valuable
(especially for federations, but also for passwords), and FIDO is a good
example of a set of proposals that seem to entirely require additional
interaction above and beyond filling a form. I haven't seen a
counter-proposal for those pieces.


You're convinced me that an imperative method for saving (local) 
credentials is useful but I don't think we need new interfaces and 
objects surrounding it when we have the autocomplete values. See 
https://github.com/w3c/webappsec-credential-management/issues/13



I'm inclined to continue pursuing this more imperative proposal, as it
seems flexible enough to support the use cases we know we have today, and
those we'll discover in the future. The developers I've spoken with see the
API as an improvement and have been able to layer it on top of existing
sign-in systems with minimal change to their authentication backends
(which, as probably won't surprise you, are _always_ the oldest,
least-well-understood, and most fragile bits :) )**. I think it's worth
exploring.

-mike

* I also agree with him that sign-up is an important use-case, and that we
should do the work to support it. Anyone interested in working with me on a
draft proposal for what that might look like?


This is already specified in the requestAutocomplete[1] section of the 
HTML specification so I think it's probably (close to being?) ready to 
implement already. The other part for XSS protection is @writeonly[2] 
which can be added to the HTML spec. I'm not sure what else you have in 
mind but I can try help.


Matthew

[1] https://html.spec.whatwg.org/#dom-form-requestautocomplete
[2] 
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Oct/0181.html

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

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Matthew N.]

On 2016-03-14 2:02 AM, Mike West wrote:

Hey folks! Glad to see that there's interest in this API from Mozilla. :)

On Sun, Mar 13, 2016 at 10:15 AM, Martin Thomson  wrote:


On 12 Mar 2016 7:28 PM, "Anne van Kesteren"  wrote:

It should be identical to password manager integration.


But it is not,  though I suppose that a password manager might be
exploited to store state. I hope that isn't possible... (note to self,
attempt this attack)


Credential managers guess at a user's username and password, and ask the
user if they'd like to persist that information.


They only guess because authors don't know about or aren't using the 
HTML autocomplete values to markup this information: 
https://html.spec.whatwg.org/#attr-fe-autocomplete-username


One of my criticisms of this spec is that sites can already use these 
attributes and form submissions so password managers don't need to use 
heuristics for identifying login credentials so why do we need another 
way of doing this?



It's generally stored
outside of "site data" (cookies, localstorage, IDB, etc), and users
generally treat it differently (anecdotally: ~12.9% of Chrome's users
who've opted into sharing usage data cleared cookies in the last week;
~2.7% cleared passwords). I think this distinction is pretty much in line
with user expectation.

This API offers a few things that the status quo cannot: Imperative
certainty about the data being persisted as opposed to heuristic guessing,


This could be built on top of  instead of creating new interfaces. 
See https://github.com/w3c/webappsec-credential-management/issues/13 for 
a proposal.



XSS mitigation,


I disagree that the status quo "cannot" (it simply "does not" IMO) as 
I've explained in other threads how most, if not all, of these can 
mitigations can be applied to / mostly using your 
@writeonly proposal: 
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Oct/0181.html



federation hints,


This is possible via new @autocomplete values too or could be its own 
API and/or spec.



and automatic sign-in for users who have
done whatever dance the UA requires to enable such a feature.


This could also be implemented on top of /rAc for local credentials.


I don't believe, however, that it offers additional tracking capability
above and beyond the (quite intentional) capabilities inherent in a
credential manager. Sites are not granted any ability to persist data
without user knowledge; they are only granted control over the timing of
the prompt, but the prompt itself is still required. Nor are sites granted
the ability to read data without user knowledge; users are either directly
involved in handing credentials over to a site, or they grant the UA
permission to hand credentials over.

As we add more credential types (FIDO, etc), we'll certainly need to ensure
that we don't introduce privacy footguns, but I think we're capable of
maintaining that dicipline.


In that case, credentials stored by a site should last no longer than
cookies. Credentials created by a user maybe can live longer.


How do you distinguish the two if the access is through a UI-mediated

API?

If credentials created in response to a `get()` call are stored at the
point they are created, you could treat calls to `store()` very
differently. Maybe. If the intent is to use a password manager, see
Richard's earlier mail.


I'm not sure, but it sounds like this is based on some misunderstanding of
what the API offers. Does the above description ease your concerns? Or am I
missing the critique?


If we think this API should have no more power than storage/cookies,
there's not much point in having this API.


Yes, the source of my concerns, right there. Sure, the fig leaf might
allow us to convince ourselves that we aren't creating a tracker that
trumps the rest.

If we are creating something that is somehow greater out of the framework
this provides (FIDO), then that is useful. But the stepping stone we are
being offered on that path looks suspicious. Why not go straight for the
real prize?


Websites use passwords today. While I agree that we can and should be
working on something better, I don't think that we should overlook small
improvements in the status quo. We can give users a better experience on
their favourite sites if we allow developers to bypass status quo
heuristics, and we keep users safer if we mitigate some of the XSS risks of
password managers today. I think this API does both, and is worth
experimenting with to see if it's a framework we can build upon.


I agree there are ways to improve the status quo but I think there are 
more incremental improvements like imperative storing of credentials in 
a  (issue #13), support for @writeonly for XSS mitigation, and 
promoting/improving requestAutocomplete for login/registration that are 
less complex and more backwards-compatible.


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

Re: Intent to implement: W3C WebAppSec credentialmanagement API

[Matthew N.]

On 2016-03-10 12:07 PM, Ben Kelly wrote:

I believe Matthew Noorenberghe had some concerns about the necessity of the
API given requestAutocomplete:


https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/7ouLjWzcjb0/s7aZHGnlAwAJ
  https://github.com/w3c/webappsec-credential-management/issues/2

We should probably come to some consensus there before moving forward.


Axel was already on a thread about this concern before sending out the 
intent to implement so I'm not sure why this intent was sent out a day 
later when the concerns weren't yet addressed.


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

Re: firefox-ui-tests are now in mozilla-central with TaskCluster support

[Matthew N.]

CC: firefox-dev

On 2016-03-01 5:17 AM, Henrik Skupin wrote:

Over the last years the formerly known Mozmill tests and now Firefox ui
tests have been located in their own repository. That meant that we
always got regressions due to changes developers have been made in
Firefox. Hunting down those regressions and fixing them was always a
time consuming job. Beside all that we were also responsible for merging
our branches accordingly to our 6 week cycle.


Hi Henrik, thanks for sharing.

Could you give an overview of what is tested by this suite and how it 
differs from mochitest-browser-chrome? It seems one difference is that 
some(?) tests run on non-en-US.


Could you also add a description to 
https://developer.mozilla.org/en-US/docs/Mozilla/QA/Automated_testing?


Thanks,
Matthew N. (:MattN)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Making it easier to file performance bugs?

[Matthew N.]

On Sat, Feb 13, 2016 at 12:33 PM, David Rajchenbach-Teller
 wrote:
> 1/ find a product/component in which to file it (which is the original
> issue);
Not with the guided bug form that I believe new accounts get, you only
need to pick the product and all reports go to Untriaged (for
Firefox).

> 2/ know that keywords in general exist, and this keyword in particular;

Not with the bug fix that I pointed to and which there is agreement on
implementing.

> 3/ (I believe) have editbugs rights.

Again, not with 1050252 fixed.

Your proposed solution wouldn't work for the people who don't choose
the more advanced flow that lets you choose a component.
https://bugzilla.mozilla.org/enter_bug.cgi?format=guided#h=bugForm|Firefox
doesn't even have a component picker. See
https://bugzilla.mozilla.org/enter_bug.cgi?format=guided for the
starting point where reporters would have to know to use the textbox
at the bottom instead of the big icons for your flow.

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

Re: Making it easier to file performance bugs?

[Matthew N.]

Note that we already have the "perf" keyword that can be filtered on
and  https://bugzilla.mozilla.org/show_bug.cgi?id=1050252 was filed to
add a checkbox to the guided bug form to easily add this keyword to
new bugs. I see that keyword still used regularly by regular
contributors.

Have you considered using bugzilla whine emails to receive a list of
all new bugs with that keyword. You could narrow it down to the
"Untriaged" component(s) if you wish.

Cheers,
Matthew N. (:MattN)

On Sat, Feb 13, 2016 at 4:50 AM, David Rajchenbach-Teller
 wrote:
> So, complaints about the performance of Firefox are a pretty common
> topic. Performance bugs, on the other hand, are quite rare and/or lost
> in noise, even when they are submitted by advanced users. While
> Telemetry gives us have hard numbers on performance, intuition suggests
> that we are lacking data on the operations and websites that *feel* slow.
>
> I believe that one of the problems is that, to file a performance bug,
> users need to attach it to a precise component, which results in people
> giving up and/or attaching it randomly.
>
> One possible solution would be to:
> - add a component Firefox > Performance (and also Thunderbird >
> Performance, etc.) to Bugzilla, which would cover all untriaged
> performance issues (including web content, ux, e10s, ...);
> - have people triaging these issues to likely features involved.
>
> What do you think?
>
> Cheers,
>  David
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using browser stored credentials for http://mywebsi.de also on https://mywebsi.de

[Matthew N.]

Emma is correct that this is the solution for your problem and we are 
aware that it's important for the adoption of HTTPS. We already 
implemented the first half to support the upgrade of the form @action 
from HTTP to HTTPS in Firefox 41 but bug 667233 is needed to handle the 
form's origin being upgraded.


MattN

On 2015-11-25 10:11 AM, Emma Humphries wrote:

I've been reviewing Password Manager bugs the past few days, and the
https/http issue has been bugged:
https://bugzilla.mozilla.org/show_bug.cgi?id=667233 and has recent
activity. It has an owner, and a priority.

On Wed, Nov 25, 2015 at 10:06 AM, Thomas Schäfer
 wrote:

Am Mittwoch, 25. November 2015 19:51:11 UTC+2 schrieb Philipp Wagner:

Am 25.11.2015 um 18:33 schrieb Boris Zbarsky:

On 11/25/15 12:24 PM, Thomas Schäfer wrote:

No, the are stored using the mechanism firefox offers for storing
credentials (Settings -> Security).


So these are HTTP Auth credentials (based on 401 responses from your
server)?


I guess the OP is talking about passwords auto-filled into form fields?

Philipp


Yes. Maybe I didn't made myself clear enough on that point: I am talking about 
the auto-filled form fields where the auto-fill works on the non-ssl version of 
the page (where they were originally saved) and does not work on the ssl 
version of the page including the same form.

Thomas


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

Re: Telemetry Dashboards

[Matthew N.]

On 2015-08-19 1:59 PM, azha...@gmail.com wrote:

 Evolution dashboard:
 Enumerated histograms.
 Boolean histograms.
 Histogram dashboard:
 Keyed histograms.


Thanks Anthony! I've been looking forward to reports like these for a 
long time.


Matthew N. (:MattN)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Can we make a plan to retire Universal Mac builds?

[Matthew N.]

On 2015-08-05 4:28 PM, Martin Thomson wrote:

On Wed, Aug 5, 2015 at 3:59 PM, Matthew N.  wrote:

If we have data on CPU architecture I don't think the OS version is relevant
unless I'm missing something.


My understanding is that OS version is all that matters.  64-bit apps
require a 64-bit OS.  (Such an OS requires a 64-bit processor of
course.)


All of our supported versions of OS X can run on 64-bit hardware[1] 
though AFAICT.


[1] "Platforms:	IA-32, x86-64[2]" 
https://en.wikipedia.org/wiki/Mac_OS_X_Snow_Leopard

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

Re: Can we make a plan to retire Universal Mac builds?

[Matthew N.]

Assuming our FHR data is gathering correct data:

1.5% of our OS X users are on x86. (There is no date on the dashboard 
I'm looking at)


If we have data on CPU architecture I don't think the OS version is 
relevant unless I'm missing something.


Matthew N. (:MattN)

On 2015-08-05 3:02 PM, Syd Polk wrote:

So, in March of 2015, these were our usage stats:

32.20%  10.10 (14.0.x) (Yosemite)
27.98%  10.9 (13.0.x) (Mavericks)
19.22%  10.6 (10.0.x) (Snow Leopard)
11.06%  10.7 (11.0.x) (Lion)
9.53%   10.8 (12.0.x) (Mountain Lion)

I have requested a more modern run from Brendan, who gave Clint Talbert and me 
these numbers. Let’s see what current data tells us. I am also curious if we 
can tell 32 vs. 64-bit in our numbers.

Syd Polk
sp...@mozilla.com
+1-512-905-9904
irc: sydpolk






On Aug 5, 2015, at 16:49, Eric Shepherd  wrote:

Syd Polk wrote:

I don’t think we can do this until we stop supporting Mac OS X 10.6. Last time 
we calculated percentage of users, this was still over 15%. I don’t think that 
very many of them would be running 64-bit, either. 10.7 has that problem as 
well, but it is a very small percentage of users.

Those are worthwhile stats to double-check.

--

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/ <http://www.bitstampede.com/>
Twitter: http://twitter.com/sheppy <http://twitter.com/sheppy>
Check my Availability <https://freebusy.io/esheph...@mozilla.com>




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

Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25

[Matthew N.]

On 8/19/14 12:22 PM, Jonathan Griffin wrote:

To assess the impact of doing this, we will be performing an experiment
the week of August 25, in which we will run debug tests on
mozilla-inbound on most desktop platforms every other run, instead of
every run as we do now.  Debug tests on linux64 will continue to run
every time.  Non-desktop platforms and trees other than mozilla-inbound
will not be affected.


To clarify, is fx-team affected by this change? I ask because you 
mention "desktop" and that is where the desktop front-end team does 
landings. I suspect fx-team landings are less likely to hit debug-only 
issues than mozilla-inbound as fx-team has much fewer C++ changes and 
anecdotally JS-only changes seem to trigger debug-only failures less often.



This approach is based on the premise that the number of debug-only
platform-specific failures on desktop is low enough to be manageable,
and that the extra burden this imposes on the sheriffs will be small
enough compared to the improvement in test slave metrics to justify the
cost.


FWIW, I think fx-team is more desktop-specific (although Android 
front-end stuff also lands there and I'm not familiar with that).


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

Re: Telemetry alerts for histograms

[Matthew N.]

I would prefer a public list available over NNTP like 
mozilla.dev.tree-management so I don't have to get the large volume of 
mail in my inbox.


MattN

On 8/12/14 5:17 PM, Gavin Sharp wrote:

What does that alias point to? Seems to me a public mailman mailing
list would be a better choice, since then people can
subscribe/unsubscribe on their own.

Gavin

On Tue, Aug 12, 2014 at 7:57 AM,   wrote:

 From now on all alerts will be sent by default also to 
telemetry-ale...@mozilla.com.


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

Re: Is it time for mochitest-chrome on Android and B2G

[Matthew N.]

On 6/17/14 4:32 PM, Jonathan Griffin wrote:

Many of those tests don't apply to Android or B2G, and for those that
theoretically do, many of them won't work because they rely on XUL
files which aren't supported in B2G, and may not be in Android (not
sure on that point).


I'm told Android uses XUL in some cases so it should work but I don't 
know how well it's "supported" outside of what Android actually needs/uses.


On 6/18/14 11:25 AM, jmaher wrote:

Could you give some examples of what tests we could run on mobile in chrome?


From a quick skim, I believe the majority of mochitest-chrome tests 
could run on mobile.


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

Intent to implement: New HTMLInputElement.autocomplete values

[Matthew N.]

Summary: I am implementing support for @autocomplete values other than 
"off"/"on" for HTMLInputElement.autocomplete. This allows web developers 
to indicate how UAs should autocomplete/auto-fill values in the fields 
(if they choose to do so) so they don't have to use heuristics to guess 
what data is expected.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1009935
Link to standard: 
http://www.whatwg.org/specs/web-apps/current-work/#attr-fe-autocomplete
Platform coverage: New values/tokens will be preffed on in the future 
for platforms which make use of the associated values so that websites 
can do feature detection.
Estimated or target release: The main consumer is requestAutocomplete[1] 
although some of the values may be used by form manager and password 
manager before that point.
Preference behind which this will be implemented: 
dom.forms.autocomplete.experimental
We may use additional preferences or change the name once we know which 
values we will initially support for requestAutocomplete and the 
password manager.


FYI: The various attribute values have been in the web-apps spec for 
over a year and Chrome is already making use of them for 
requestAutocomplete and, I believe, inline form auto-fill.


[1] 
https://groups.google.com/d/topic/mozilla.dev.platform/F2mMPBme40I/discussion


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

Re: Proposal: New BMO Toolkit component for Notifications and Alerts

[Matthew N.]

The component was added in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1013763 and it was pointed 
out that I was originally missing the prompt service from the list of 
related code so that has now been added to the description.


I've done some bulk moves of open bugs so the component now has about 
120 of them (this was done fairly quickly to seed the component). You 
can filter bugmail on "notifications-and-alerts-component" to find the 
changes from the bulk move (e.g. to mark them as read).


Current bug list: 
https://bugzilla.mozilla.org/buglist.cgi?component=Notifications and 
Alerts&product=Toolkit&bug_status=__open__


A reminder to watch the component and/or update saved searches if that's 
relevant to you.


Happy bug filing/triaging!
Matthew N.
:MattN
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Proposal: New BMO Toolkit component for Notifications and Alerts

[Matthew N.]

Hello,

I think the various notification features outlined below are big enough 
to deserve their own Toolkit component on bugzilla.mozilla.org. The 
scope of the component would be changes to:
(i) PopupNotifications.jsm – Page-related popup (aka. doorhanger) 
notifications
(ii) notification.xml - Notification Bars (usually application 
notifications)
(iii) toolkit/components/alerts/ – Alert service including fallback XUL 
UI when we don't integrate with a more native service (e.g. OS X 
Notification Center).


(i) and (ii) are currently filed in either Firefox::General or 
Toolkit::General while bugs for (iii) are currently filed in 
Toolkit::XUL Widgets.


I propose the component be named "Notifications and Alerts" in the 
Toolkit product with the description "Popup/doorhanger notifications, 
notification bars, and alerts".


Thoughts?

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

Re: Proposed changes to autocomplete administrative levels

[Matthew N.]

On 5/15/14, 8:21 AM, Ehsan Akhgari wrote:> On 2014-05-15, 5:29 AM, Anne 
van Kesteren wrote:

>> On Wed, May 14, 2014 at 1:52 AM, Brian Nicholson
>>  wrote:
>>> If we disagree with this proposal:
>>>
>>> What alternatives do we have? Given that countries require more than
>>> two administrative levels in postal address, it seems our options are
>>> limited. We can't simply provide a single blob for an entire address
>>> as sites generally require more tokenized information.
>>
>> You do not want to tie this to a particular localization. E.g. I use
>> the en-US version of Firefox, but I make payments with European credit
>> cards. Localization should not affect functionality.
>
> Yes, this should definitely be tied to the locale of the page not the UA.

If you're referring to which fields to show in the requestAutocomplete 
(rAc) UI, the ideal plan IMO would be to tie it to the country the user 
chooses in their autocomplete profile in the browser. So if I choose 
China as the country, I will see the three (or soon four) levels of 
address fields required, whereas choosing USA will only have City and 
State. The field labels would be in the language of the UA but would be 
localized for the country chosen.


> Do you know if Chromium or any other projects have an open source
> version of this mapping that we can use at least as a baseline?

If you are referring to the localized names for all of the level fields 
in each region, then I don't know about such a mapping but I haven't 
looked for one.


I believe Chromium is planning on using libaddressinput (that Brian 
linked to) in order to know which fields are required and the proper 
order. Unfortunately it only supports two address levels at the moment 
though.

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

Re: Toolkit sub-module Preferred Reviewers who are not Toolkit Peers

[Matthew N.]

Thanks for clarifying.

Myself, Jared Wein, and Paolo Amadini (Download Manager Owner) seem to 
be missing from the Toolkit peer list then.


Thanks,
Matthew

On 1/19/14, 8:47 PM, Dave Townsend wrote:

Everyone who is a preferred reviewer should be a peer, if they aren't it's
likely because I forgot to update the appropriate lists. Who do you see who
is absent from the peer list?


On Sat, Jan 18, 2014 at 11:51 AM, Matthew N.  wrote:


Hello,

What does it mean to be a "Preferred Reviewer" (previously called a
"peer") in a Toolkit sub-module[1] and not be on the list of Toolkit
Peers[2]? The Toolkit Code Review page[3] doesn't seem to cover this case.

Specifically:
1) Can a "Preferred Reviewer" review code in the related submodule without
oversight from the sub-module owner?
2) Is a sub-module "Preferred Reviewer" considered a "Toolkit reviewer"
for the purposes of [3]?

Thanks,
MattN

[1] https://wiki.mozilla.org/Toolkit/Submodules
[2] https://wiki.mozilla.org/Modules/Toolkit
[3] https://wiki.mozilla.org/Toolkit/Code_Review
___
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

Toolkit sub-module Preferred Reviewers who are not Toolkit Peers

[Matthew N.]

Hello,

What does it mean to be a "Preferred Reviewer" (previously called a 
"peer") in a Toolkit sub-module[1] and not be on the list of Toolkit 
Peers[2]? The Toolkit Code Review page[3] doesn't seem to cover this case.


Specifically:
1) Can a "Preferred Reviewer" review code in the related submodule 
without oversight from the sub-module owner?
2) Is a sub-module "Preferred Reviewer" considered a "Toolkit reviewer" 
for the purposes of [3]?


Thanks,
MattN

[1] https://wiki.mozilla.org/Toolkit/Submodules
[2] https://wiki.mozilla.org/Modules/Toolkit
[3] https://wiki.mozilla.org/Toolkit/Code_Review
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [RFC] Cleaning up sessionstore.js

[Matthew N.]

On 11/28/13, 7:15 AM, Honza Bambas wrote:

On 11/28/2013 12:56 PM, David Rajchenbach-Teller wrote:

As many of you know, Session Restore is something of a performance hog,
for many reasons – we have reports of. One of the reasons is that we
store so very many things in sessionstore.js and sometimes keep stuff
for a very long time.


Do we know that these issues affect a large number of users and not just 
tab hoarders like myself?



So, here are a few things that I believe we could cleanup:
1. get rid of closed windows after a while;

Definitely, also from a privacy POV.

2. get rid of closed tabs after a while;

Ditto

3. get rid of old history entries of open tabs after a while;
4. get rid of POST data of history entries after a while;
5. get rid of DOM storage contents of open tabs after a while;
6. get rid of form data content of open tabs after a while;

4-6: from a user POV - I have to agree also with Till, I really like
that form data are not lost *for ages*, I always write a bug report and
then leave it unsent to collect more data first, as well as any bug
comments.  And I'm really enjoying how well Fx keeps these data
unbroken.  That should stay.


I agree that #1 and #2 should expire but I don't think expiring 3-6 is 
worth the loss of functionality and trust in the browser. Fixing #1 and 
#2 would also probably reduce the need for 3-6 since the browser default 
is to open the homepage on every launch instead of restoring the session 
and we know that most users don't change defaults.


It's not uncommon for me to go back to a tab group for a side project 
that I haven't worked on for a few months and want to resume where I 
left off. #3, #4, and #6 would definitely hinder that. It's hard to say 
if #5 would without knowing how websites are using DOM storage. To be 
clear, is that just referring to window.sessionStorage?


Cheers,
Matthew N. [:MattN]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform