PWA Support

[Tom Schuster]

Hello all!

I must say I am quite surprised that there is apparently no plan to
support PWAs?
https://bugzilla.mozilla.org/show_bug.cgi?id=1682593#c8
That seems like a very short-sighted decision at this point. I just
recently saw this article about some drawing APP abandoning Electron
in favor of PWAs:
https://blog.excalidraw.com/deprecating-excalidraw-electron/.

Can we at least keep SSB for now? I might look into fixing some of the
bugs, but that is of course not a sustainable solution.

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

Re: Intent to unship: window.external.AddSearchProvider

[Tom Schuster]

As the author of one of these extensions for adding a custom search
engine 
(https://addons.mozilla.org/en-US/firefox/addon/add-custom-search-engine/)
I am of course disappointed, but not actually surprised. This is
basically round two from about a year ago. I would like to point out
that it would be very simple to only expose this API to extensions. I
am going to fallback to  for now, which is sadly a
lot less obvious to users.

One reason the previous try of deprecating this API was reverted was
the usage of AddSearchProvider by mycroftproject.com/. I see you
didn't address this issue in your intent to unship.

I agree that we should probably remove this API for normal web-pages
considering the potential for abuse and just the general annoyance of
prompts. But again my plea: please consider adding proper custom
search engine support to Firefox itself. Even Fenix has support for
adding custom search engines! Not even talking about probably every
other Chrome based browser on Desktop. This is seriously a missing
piece of customization in Firefox.

Best,
Tom

On Thu, Apr 23, 2020 at 12:43 PM Mark Banner  wrote:
>
> As of Firefox 78, I intend to change `window.external.AddSearchProvider`
> in Firefox to be a dummy function. This will be a preference switch
> initially, with the original implementation code being removed fully in
> Firefox 79.
>
> /Status/:
>
>   *
>
> The HTML Standard specifies this method
> as
> "must do nothing".
>
>   *
>
> Internet Explorer: This feature was supported in IE7-9 but
> deprecated in IE10+ and not present in Edge.
>
>   *
>
> Chrome: Changed to no-op in 54.
>
>   *
>
> Safari: No support.
>
> Product: Mike Connor.
>
> Bug to unship: Preference disable
> , Remove code and
> preference .
>
> Reasons: `AddSearchProvider` allows adding OpenSearch providers from a
> website page. This has been deprecated by the WHATWG, and IE and Chrome
> no longer support it. As far as I know it has never been supported on
> Mobile.
>
> This API allows a website to put up unsolicited repeated prompts to
> users. It is vulnerable to potential DoS
> attacks
> .
>
> For websites wanting to provide their own engines, the alternative is to
> include the  tag, or to provide their own add-ons
> which add search engine providers.
>
> Add-ons that use the API would no longer work. Of the two add-ons we
> have found that use the API, they are both ways of adding custom search
> engines. They both have small numbers of users. Whilst we acknowledge
> this will remove some functionality for users, we would encourage users
> to request that websites provide their own search integrations which
> would have the advantage of being maintained by the website, and being
> available to everyone.
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Autodiscovery of WebExtension search engines

[Tom Schuster]

I would also like to mirror the previous comments: Why do we need to
expose this new non-standard feature to the web? Can't we just
transform OpenSearch XML internally to the new WebExtension format?

On Wed, Feb 26, 2020 at 1:17 PM Henri Sivonen  wrote:
>
> On Tue, Feb 25, 2020 at 10:04 PM Dale Harvey  wrote:
> > Yes,  extensions that only define a new search engine will be permitted,
> > the extension will not be able to do anything else.
>
> What capabilities do search engine-only WebExtensions have that
> OpenSearch doesn't provide?
>
> --
> Henri Sivonen
> hsivo...@mozilla.com
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: JavaScript toSource and uneval

[Tom Schuster]

In bug 1565170 I plan to disable the toSource methods that exists for
most objects in Firefox as well as the uneval method on the global
object. This change will affect all websites and WebExtension. Both
methods will still be available to Firefox internal (chrome) code, but
I plan on removing those uses as soon as possible.

Those methods were never standardized an no other browser ever supported them.

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

Re: Intent to unship: Array generics

[Tom Schuster]

We decided to try unshipping Array generics for real.

The numbers haven't improved, but I also haven't heard of any fallout
on Nightly. I am going to assume that those uses are actually already
polyfilled for another browsers.

-Tom

On Fri, Jun 28, 2019 at 6:30 PM Tom Schuster  wrote:
>
> We plan to unship the non-standard Array generic methods. These are
> copies of the methods from Array.prototype, for example Array.slice,
> Array.forEach etc. No other browser supported those.
>
> For testing I will first disable those methods only on Nightly.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1222547
> (For Nightly: https://bugzilla.mozilla.org/show_bug.cgi?id=1558914)
>
> Telemetry: https://mzl.la/2Ykw7NI
> Some methods still have high usage, but my optimistic assumption is
> that people actually have polyfills (We have seen this on multiple
> sites)
>
> Thanks,
> Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Prototype: text-decoration-skip-ink

[Tom Schuster]

Very cool, I have been looking forward to this. I hope we can enable
this for links by default at some point, like Chrome.

On Wed, Aug 7, 2019 at 12:14 AM Charlie Marlow  wrote:
>
> Summary: text-decoration-skip-ink is a CSS feature that makes underlines and 
> overlines skip around the text, instead of painting behind it. There is a 
> picture of this effect on the standards link.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1411922 
> 
>
> Standard: 
> https://drafts.csswg.org/css-text-decor-4/#text-decoration-skip-ink-property 
> 
>
> Platform coverage: This will be available on all platforms using Gecko.
>
> Preference: It will be preffed off by default under 
> layout.css.text-decoration-skip-ink.enabled
>
> DevTools bug: This is a minor, cosmetic visual feature with no clear 
> opportunity for DevTools integration.
>
> Other browsers: It works in both Chrome and Safari.
>
> Web-platform-tests: Initial reftests will be landed with the first patch, 
> they are here: https://phabricator.services.mozilla.com/D40707 
> 
>
> Secure contexts: No, it is not restricted to secure contexts in other 
> browsers, so for compatibility we don’t restrict it either.
>
>
> Charlie Marlow
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Blocking Worker/SharedWorker with non-JS MIME type

[Tom Schuster]

On Wed, Jul 24, 2019 at 3:21 AM Boris Zbarsky  wrote:>
> On 7/22/19 6:22 AM, Tom Schuster wrote:
> > This was also discussed at https://github.com/whatwg/html/issues/3255.
> > It seems like Chrome does NOT plan on shipping this at the moment.
>
> Does "at the moment" mean they are open to shipping it in the future if
> we ship it and don't run into web compat issues, or that they are not
> planning to ship at all?  What are Safari's plans here?  What is the
> proposed path to interop?
>

After asking the Chrome team for clarification
(https://github.com/whatwg/html/issues/3255), they are interested in
shipping this, but need more time and information.
So I propose restricting this change to Beta/Nightly and to wait for
them or until we see too much fallout.

> > We didn't dig too deeply into this data, but one idea was
> > that a lot of worker scripts are actually 404 text/html error pages.
>
> This is something telemetry could easily measure, yes?  Only record
> worker script types for responses that would actually get processed
> (i.e. not HTTP 4xx responses).  Is there a reason not to do that before
> shipping this change?
>

Yes that would be possible. Till now my reasoning was that blocking
importScripts was successful, even though it had higher usage. If we
are going to delay shipping this,
we might as well look into adding those counters.

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

Intent to ship: Blocking Worker/SharedWorker with non-JS MIME type

[Tom Schuster]

In Firefox 70 we plan to start blocking Worker and SharedWorker
scripts served with non-JavaScript MIME types. We have similarly been
blocking importScripts() since version 67.

Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1523706
Pref: security.block_Worker_with_wrong_mime

This was also discussed at https://github.com/whatwg/html/issues/3255.
It seems like Chrome does NOT plan on shipping this at the moment.

However we are optimistic that we can ship this, because in our data
there are more importScripts with a wrong MIME type than worker
scripts. We didn't dig too deeply into this data, but one idea was
that a lot of worker scripts are actually 404 text/html error pages.

Telemetry: https://mzl.la/2y805sN (Compare worker_load with importScript_load)

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

Intent to unship: Array generics

[Tom Schuster]

We plan to unship the non-standard Array generic methods. These are
copies of the methods from Array.prototype, for example Array.slice,
Array.forEach etc. No other browser supported those.

For testing I will first disable those methods only on Nightly.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1222547
(For Nightly: https://bugzilla.mozilla.org/show_bug.cgi?id=1558914)

Telemetry: https://mzl.la/2Ykw7NI
Some methods still have high usage, but my optimistic assumption is
that people actually have polyfills (We have seen this on multiple
sites)

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

Re: New and improved "about:config" for Firefox Desktop

[Tom Schuster]

I am always happy to see more xul going away.

Please implement a filter to only show modified preferences. Sorting
by modified is probably my most common operation after search on the
old page.

Thanks

On Fri, Jan 25, 2019 at 11:40 AM Axel Hecht  wrote:
>
> Is there a tracking bug for follow-ups?
>
> I'd have a few, adding pref w/out search (*), show add on screen for
> long searches, filter/order by modified, search in values, can't abort edit.
>
> (*) I just realize that I didn't understand how "add" works. Maybe the
> bug is to make that discoverable?
>
> Axel
>
> Am 24.01.19 um 20:31 schrieb Paolo Amadini:
> > Last year a group of students, Luke, Matthias, and Vincent, designed and
> > implemented a new version of "about:config" in order to improve the
> > ergonomics and align the look and feel with other in-content Firefox
> > pages. They did an amazing job, working with design input from Amy Lee
> > and with myself doing code reviews.
> >
> > I'm happy to announce that this work will be available to everyone in
> > Firefox 67, and can be already used in Nightly at this URL:
> >
> >  chrome://browser/content/aboutconfig/aboutconfig.html
> >
> > Most improvements are the natural result of using HTML instead of XUL:
> >
> >   * There are visible buttons for editing preferences
> >   * String values are displayed in full as multiline text
> >   * Find in page works for both names and values
> >   * Triple click selects one preference name or value quickly
> >   * Text selection works on multiple preferences
> >   * The context menu is the same as regular web pages
> >  - Copy to the clipboard
> >  - Open selected link
> >  - Search with your preferred engine
> >   * Search results don't include spurious value matches anymore
> >   * Closing and reopening the browser while the tab is pinned
> >   preserves the search term
> >
> > We've not just converted the old page, we've designed something new
> > based on actual use cases, telemetry data, and opportunity cost. We
> > preferred natural HTML page interactions, for example a double click now
> > selects text instead of toggling the value. The way the page is explored
> > with screen readers has also changed, and we've ensured that the new way
> > is still clear and easy to use.
> >
> > We're still keeping the old "about:config" around at the following URL
> > for a while, to mitigate risk related to unforeseen circumstances:
> >
> >  chrome://global/content/config.xul
> >
> > Thunderbird will not be affected by this change initially, but at some
> > point we'll remove the old code from mozilla-central since Thunderbird
> > will be the only remaining user.
> >
> >
> > *Performance*
> >
> > This page can be slower than the old one in some cases. On slower
> > machines the page may take a moment to display all preferences, if you
> > so choose. We worked around this by waiting for the first input before
> > displaying results, as 93% of "about:config" page shows include a search
> > anyway. Navigation, scrolling, and find in page are then fast.
> >
> > We've used performance profiling to optimize the page and avoid the
> > slowest layout modes, but we've not compromised on using the latest
> > best practices for Firefox Desktop like Fluent localization, which are
> > anyways in the process of being optimized on their own.
> >
> > We've explicitly chosen to avoid virtualizing the list, that is only
> > rendering visible DOM nodes, because this would add complexity that is
> > not needed for an internal page. It would also nullify most of the
> > advantages in accessibility and usability that we gained at a low cost
> > just because we're using a simple HTML table. Effort would be better
> > spent on optimizing the web for the layout of tables of about 3,000
> > rows, which would benefit every web site instead of Firefox only.
> >
> >
> > *Tutorials and screenshots on the web*
> >
> > While with some features there is a concern that a change would make it
> > more difficult for users to follow instructions found in older tutorials
> > on the web, this is much less of a concern in this case, given that the
> > page caters to experienced users and the changes affect presentation
> > rather than actual functionality.
> >
> > In fact, existing information on the web can more easily become obsolete
> > because the preferences go away or change their meaning, rather than
> > because of a change in how the values can be changed.
> >
> >
> > *Features that have not been rewritten*
> >
> > If the new page is missing a feature that the old one used to have,
> > there is probably a good reason. Luke added telemetry probes to the
> > current "about:config" so we know how people use it. It's basically just
> > one mode of operation across all channels: search, then maybe edit or
> > add a preference.
> >
> > There are more details in the history section below, but this is to say
> > that it is unlikely that we would accept a patch to add back a 

CPOWs are now almost completely disabled

[Tom Schuster]

Since landing bug 1465911 [1], CPOWs [2] are only functional on our testing
infrastructure. In normal builds that we ship to users CPOWs can be
created, but no operations like property lookup can be performed on them.

CPOWs continue to exist, because a lot of tests still depend on them. We
can't disable CPOW creation in user builds, because the context menu passes
them from the child to the parent and back like a token.

This is a significant IPC attack surface reduction.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1465911
[2]
https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Blocking FTP subresources

[Tom Schuster]

Good idea. Opened a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1452701

At least in the Chrome bug somebody was complaining that web cam page
was broken by this change. Seems like the reloading image was embedded
over FTP.

On Mon, Apr 9, 2018 at 5:54 PM, Patrick McManus <mcma...@ducksong.com> wrote:
> imo, you really need to add a pref to cover this (I'm not saying make it
> opt-in, just preffable.). It will break something somewhere and at least you
> can tell that poor person they can have compat back via config.
>
> It also has a very small possibility of breaking enterprises or something we
> would discover late, and we would want to be able to push a pref to fix
> that.
>
>
> On Mon, Apr 9, 2018 at 9:13 AM, Tom Schuster <t...@schuster.me> wrote:
>>
>> Summary: All FTP subresources in HTTPs pages (this also includes blob:
>> etc) will be blocked. Opening FTP links as toplevel documents is still
>> possible.
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1404744
>>
>> Platform coverage: All
>> Target release: Firefox 61 (this already landed, but we forgot to send
>> this, sorry!)
>> Preference behind which this will be implemented: None
>> Is this feature enabled by default in sandboxed iframes: Yes, enabled
>> everywhere
>> DevTools bug: None
>> Do other browser engines implement this?
>> Chrome shipped in M62?
>> web-platform-tests: No
>> Secure contexts: n/a
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: Blocking FTP subresources

[Tom Schuster]

Summary: All FTP subresources in HTTPs pages (this also includes blob:
etc) will be blocked. Opening FTP links as toplevel documents is still
possible.

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

Platform coverage: All
Target release: Firefox 61 (this already landed, but we forgot to send
this, sorry!)
Preference behind which this will be implemented: None
Is this feature enabled by default in sandboxed iframes: Yes, enabled everywhere
DevTools bug: None
Do other browser engines implement this?
Chrome shipped in M62?
web-platform-tests: No
Secure contexts: n/a
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Chrome will start marking HTTP pages as "Not secure"

[Tom Schuster]

If you flip just security.insecure_connection_text.enabled and not
security.insecure_connection_icon.enabled you get Chrome's behavior.
Flipping both gives you the broken lock and the "Not Secure" text. I
don't see a big difference there and I hope we can ship this as soon
as possible.

On Fri, Feb 9, 2018 at 1:55 AM, Martin Thomson  wrote:
> +ffxdev
>
> There's a tangible difference between text saying "Not Secure" and a
> broken lock icon.  I think that we're close, but we'd be making a
> stronger statement than Chrome if we did this.
>
> On Fri, Feb 9, 2018 at 8:17 AM, Chris Peterson  wrote:
>> Chrome will start marking HTTP pages as "Not secure" in July 2018 (Chrome
>> 68):
>>
>> https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html
>>
>> Firefox has a similar insecure HTTP warning icon, currently disabled by the
>> `security.insecure_connection_icon.enabled` pref added in bug 1310447.
>>
>> Are there any blockers for Firefox shipping this feature?
>> ___
>> 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: Intent to ship: Array.prototype.values

[Tom Schuster]

I plan on landing this today, so this change is going to be in Firefox
60. The pref for enabling/disabling this feature is
javascript.options.array_prototype_values.

On Fri, Feb 2, 2018 at 4:20 PM, Tom Schuster <t...@schuster.me> wrote:
> I talked to   Jan de Mooij and it's feasible to add a pref for this,
> so we are definitely going to do this.
>
> Array.prototype.values has always been enabled on Nightly. Based on
> where the breakage occurred, internal company webpages, I would not
> expect EARLY_BETA_OR_EARLIER to shake out any additional problems.
>
> On Fri, Feb 2, 2018 at 4:17 PM, Mike Taylor <mi...@mozilla.com> wrote:
>> On Feb 2, 2018, at 7:45 AM, Tom Schuster <t...@schuster.me> wrote:
>>> Any additional ideas how to mitigate the risk here? Chrome seems to
>>> want to add a kill pref for this,  from my experience more difficult
>>> for us with the way we define methods in SpiderMonkey. Should that be
>>> a requirement for shipping?
>>
>> Add a pref enabling it for EARLY_BETA_OR_EARLIER, and false otherwise, and 
>> let’s see what Nightly/Beta shakes out for a few releases. Then we have time 
>> to attempt outreach or other such hacks before burning our release users.
>>
>> --
>> Mike Taylor
>> Web Compat, Mozilla
>>
>>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Array.prototype.values

[Tom Schuster]

I talked to   Jan de Mooij and it's feasible to add a pref for this,
so we are definitely going to do this.

Array.prototype.values has always been enabled on Nightly. Based on
where the breakage occurred, internal company webpages, I would not
expect EARLY_BETA_OR_EARLIER to shake out any additional problems.

On Fri, Feb 2, 2018 at 4:17 PM, Mike Taylor <mi...@mozilla.com> wrote:
> On Feb 2, 2018, at 7:45 AM, Tom Schuster <t...@schuster.me> wrote:
>> Any additional ideas how to mitigate the risk here? Chrome seems to
>> want to add a kill pref for this,  from my experience more difficult
>> for us with the way we define methods in SpiderMonkey. Should that be
>> a requirement for shipping?
>
> Add a pref enabling it for EARLY_BETA_OR_EARLIER, and false otherwise, and 
> let’s see what Nightly/Beta shakes out for a few releases. Then we have time 
> to attempt outreach or other such hacks before burning our release users.
>
> --
> Mike Taylor
> Web Compat, Mozilla
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: Array.prototype.values

[Tom Schuster]

We already tried to ship Array.prototype.values before in Firefox 48,
but this broke
Microsoft Dynamics CRM 2011
(https://bugzilla.mozilla.org/show_bug.cgi?id=1299593). We are however
aware this might have caused other breakages as well.

The compatibility risk for this change is high.
However Chrome is going to try shipping this again (third time!)
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/yX4U__z67xo

Edge and Safari already ship this feature.

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

Any additional ideas how to mitigate the risk here? Chrome seems to
want to add a kill pref for this,  from my experience more difficult
for us with the way we define methods in SpiderMonkey. Should that be
a requirement for shipping?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: performing cross-context instanceof checks

[Tom Schuster]

This could be an issue for WebExtensions as well. I think the contentscript
sandbox runs in a different compartment.

On Thu, Jan 11, 2018 at 3:58 PM, Gijs Kruitbosch 
wrote:

> On 11/01/2018 05:29, Cameron McCormack wrote:
>
>> For use in the meantime, I just landed bug 1428531 on inbound, which adds
>> a new chrome-only static method "isInstance" to Web IDL defined interfaces,
>> so you can write for example:
>>
>>Document.isInstance(otherWindow.document)
>>
>> So that we don't have even more call sites we need to fix up once we
>> start looking at bug 1360715, please try to use isInstance rather than
>> instanceof if you need to do cross-context DOM object tests from chrome JS.
>>
>
> Assuming we're happy to update all sites (not only sites where we're sure
> the DOM instance is sometimes cross-context), this type of thing is
> relatively easy to automatically rewrite with an xpcshell script like the
> ones Florian has been using to update other conventions (e.g. use of
> Services.prefs instead of manually Cc[...].getService(Ci.nsIPrefBranch)
> etc. ). If we rewrite the extant callsites, we can add eslint checks that
> warn and can do similar rewrites for people, which will be better at
> avoiding new callsites than just convention (which people are liable to
> forget in a few days/weeks/months), and would make the transition
> relatively "easy".
>
> ~ Gijs
>
> ___
> 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: Phabricator/Lando update, November 2017

[Tom Schuster]

There are also various Firefox extensions that can manage 2 factor accounts
for you.

On Tue, Dec 5, 2017 at 3:10 PM, Byron Jones  wrote:

> TOTP does not require a smartphone.
>
> there's software TOTP clients that can be run on your desktop, and i'm
> also seeing TOTP support baked into some password managers.  that clearly
> isn't as secure as the second factor implemented on a second device,
> however desktop TOTP does provide better security than password-only
> authentication.
>
> if you care about security and shun smartphones there are also plenty of
> "one time password token" hardware devices that perform the same function.
> i have a yubikey for my 2fa needs, mostly because it's more convenient than
> reaching for my phone.
>
>
> -glob
>
>
> Masatoshi Kimura wrote:
>
>> I went to the 2FA preference on BMO. For me, the only authentication
>> option was TOTP that requires a smartphone. I do not have a smartphone
>> like Mark.
>>
>> How can I continue to contribute after we are forced to use Phabricator?
>> Mozilla no longer wants volunteer contributors?
>>
>> On 2017/11/30 3:05, Mark Côté wrote:
>>
>>> Right, I should have mentioned that. We are working right now on
>>> enforcing
>>> MFA for Phabricator via BMO. See
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1393950. Should go out next
>>> week.
>>>
>>> Mark
>>>
>>> On Nov 29, 2017 12:41 PM, "Andreas Tolfsen"  wrote:
>>>
>>> Also sprach Mark Côté:

 We were hesitant to advertise this too widely in order not to create
> any confusion around the Quantum release, but now that that has
> settled down I am told it should be fine for anyone to start using
> it.  The instance is at https://phabricator.services.mozilla.com/
> and there are docs at
> https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html.
>
 I’ve been wanting to try out the new review tool, but the sign up
 steps in the documentation fails to mention two-factor authentication.
 The only option is ‘Mobile Phone App (TOTP)’ and if you, like me,
 don’t have a smartphone it is seemingly impossible to create an
 account.

 I would’ve thought it would delegate the MFA bit to Bugzilla, or
 am I doing something wrong?


 ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>>
> --
> glob — engineering productivity — moz://a
>
>
> ___
> 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: Proposal: Stop using Object.freeze/Object.seal on most of our Javascript Objects

[Tom Schuster]

Please don't use proxies unnecessarily. They are bad for performance.

On Mon, Nov 20, 2017 at 5:05 PM, Joe Hildebrand 
wrote:

> You could also potentially use a Proxy object:
>
> https://gist.github.com/hildjj/1ac6e3d52e4e0d23f6289d73c1840a5a
>
> > On Nov 20, 2017, at 9:00 AM, Richard Newman  wrote:
> >
> > Are there alternative ways we could achieve the same without the (or
> with low) complexity/overhead?
> >
> > If I'm understanding correctly what you're trying to do, the typical
> suggestion here is to not use global singletons. That way you don't need to
> dig into the guts of a globally visible object in order to test it; you can
> pass your own part-mocked Object instance into whatever mechanism is trying
> to call `Object.foo`.
> >
> > In your `foo`/`bar` case, you'd pass a `MockObject` to `bar`, and verify
> that `MockObject.foo` was called. We do this all the time in codebases that
> use less dynamic languages (e.g., Fennec and Firefox for iOS).
> >
> > This doesn't help you to test existing singleton-based JS code… but
> then, if that code is already using Object.freeze, then you already can't,
> and you'll be having to change _something_.
> >
> > I mostly agree with Nicolas's sentiment; poking at the guts of code
> outside your own module (or even in your own module!) isn't really a kind
> of software development that I feel we should encourage. If we find that
> gut-poking is the only good way to write tests for a component, then I
> would rather we revisit the design of the component instead of making it
> mutable. Refactoring for testability is A-OK in my book.
> > ___
> > firefox-dev mailing list
> > firefox-...@mozilla.org
> > https://mail.mozilla.org/listinfo/firefox-dev
>
> —
> Joe Hildebrand
>
> ___
> 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: Change: Performance bugs handling and triaging

[Tom Schuster]

Hey!

Let me start by saying that to me Quantum Flow felt like hugely important
work that made an immediate impact on how people perceive Firefox
performance.
I am really excited that we are going to continue working on this.

You often hear people complaining about performance on YouTube and Twitch
etc. Both of these have or had beta versions of their new layouts. I think
we should be more proactive about looking at those to
find performance issues that are going to bite us later. Is there some
reference list of sites we care about in particular, so that we always keep
up with the newest or upcoming version of those?

Just as a quick observation: I tried the twitch beta about a week ago in
Firefox and felt about twice as slow as Chrome. It still takes them a very
long time to load everything, so twitch really needs to look into their
perf as well.

On Thu, Oct 19, 2017 at 9:40 PM, Boris Zbarsky  wrote:

> Naveed,
>
> Thank you for continuing work on performance!
>
>
> New profiles that require analysis should be assigned to relevant domain
>> experts.
>>
>
> Do we have a plan for _generating_ profiles, or at least incentivizing
> generation thereof?  This is a large part of what the Quantum Flow effort
> was about, though I think Ehsan did most of this part of the work.  It
> would be good to scale it better.
>
> -Boris
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Web Authentication

[Tom Schuster]

Hi J.C.!

Thanks for your extensive answer! Seems like there is a lot of progress
going on that wasn't immediately obvious from bugzilla. I am looking
forward to seeing this land.

Thank you,
Tom

On Wed, Apr 12, 2017 at 2:46 AM, J.C. Jones <j...@mozilla.com> wrote:

> Tom,
>
> We're making progress on supporting the USB U2F HID token attestation
> format; before the actual U2F/HID code starts appearing in-tree, there's
> had to be some refactoring to handle things in a proper asynchronous way --
> which is nearing review.
>
> I'm working on that USB U2F support for OSX right now; Linux support is
> also looking pretty OK, and we're planning to get Windows this quarter, too.
>
> Independently, we're waiting on updating our Web Authentication
> implementation from the WD-02 version currently in-tree, expecting a
> significant refactor to happen aligning the way you use Web Authentication
> with the W3C Credential Management specification. There's ongoing
> discussion [1] and currently one pull request [2] to do that. That's
> primarily why we haven't moved forward to the WD-04 draft yet - and we're
> working on the HID support.
>
> That said, we're still planning on exposing the USB U2F security key-type
> devices only through the W3C Web Authentication API by default -- the older
> FIDO U2F API that is currently hidden behind the `security.webauth.u2f`
> preference [3] we're currently planning to keep hidden. It doesn't
> implement the "Low-level MessagePort API", which makes a some sites that
> depend on Chrome's u2f-api.js behave oddly.
>
>
> [1] https://lists.w3.org/Archives/Public/public-webauthn/2017Apr/0162.html
> [2] https://github.com/w3c/webauthn/pull/384
> [3] (and also the `security.webauth.u2f_enable_softtoken` preference,
> since there's no USB support in-tree yet)
>
> Cheers,
> J.C.
>
> On Tue, Apr 11, 2017 at 5:05 AM, Tom Schuster <t...@schuster.me> wrote:
>
>> So what's our status with regards to implementing FIDO u2f? I really would
>> like to use my security key natively in Firefox.
>>
>> Best,
>> Tom
>>
>> On Sat, Dec 3, 2016 at 5:47 AM, Anders Rundgren <
>> anders.rundgren@gmail.com> wrote:
>>
>> > On Friday, December 2, 2016 at 10:27:30 PM UTC+1, JC Jones wrote:
>> > > Anders,
>> > >
>> > > The first target I'm working on is Desktop, though I've plans in 2017
>> to
>> > > support WebAuthn on Android and iOS [1], too. WebAuthn already has
>> > > definitions suitable for Android's Key Attestation [2] and SafetyNet
>> > > formats [3], so they'll need implementations that tie into the
>> > > dom::WebAuthentication class.
>> >
>> > That's great news!
>> >
>> > Regards,
>> > Anders
>> >
>> > >
>> > > Cheers,
>> > > J.C.
>> > >
>> > > [1] https://wiki.mozilla.org/Security/CryptoEngineering#
>> > Web_Authentication
>> > > [2] https://w3c.github.io/webauthn/#android-key-attestation
>> > > [3] https://w3c.github.io/webauthn/#android-safetynet-attestation
>> > >
>> > > On Wed, Nov 30, 2016 at 10:54 PM, Anders Rundgren <
>> > > anders.rundgren@gmail.com> wrote:
>> > >
>> > > > On Wednesday, November 30, 2016 at 5:42:30 PM UTC+1, Anders Rundgren
>> > wrote:
>> > > > > It is a pity that external tokens have become the
>> > > > > focus when the majority will rather rely on embedded
>> > > > > security solutions which nowadays is a standard feature
>> > > > > in Android and Windows platforms.
>> > > >
>> > > > Slight clarification to the above: The IoT folks pretty much build
>> > 100% on
>> > > > embedded security with car-keys as an obvious exception.
>> > > >
>> > > > On mobile I would say that over 99% of all existing security
>> solutions
>> > > > based on cryptographic keys are relying on embedded (or "App level")
>> > keys
>> > > > with Apple Pay as the most advanced example.
>> > > >
>> > > > That is, the token vendors and security folks do not represent the
>> > actual
>> > > > market comprising of end-users and service providers.
>> > > >
>> > > > Maybe this is a project primarily targeting the desktop?
>> > > > ___
>> > > > dev-platform mailing list
>> > > > dev-platform@lists.mozilla.org
>> > > > https://lists.mozilla.org/listinfo/dev-platform
>> > > >
>> >
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>> >
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Web Authentication

[Tom Schuster]

So what's our status with regards to implementing FIDO u2f? I really would
like to use my security key natively in Firefox.

Best,
Tom

On Sat, Dec 3, 2016 at 5:47 AM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On Friday, December 2, 2016 at 10:27:30 PM UTC+1, JC Jones wrote:
> > Anders,
> >
> > The first target I'm working on is Desktop, though I've plans in 2017 to
> > support WebAuthn on Android and iOS [1], too. WebAuthn already has
> > definitions suitable for Android's Key Attestation [2] and SafetyNet
> > formats [3], so they'll need implementations that tie into the
> > dom::WebAuthentication class.
>
> That's great news!
>
> Regards,
> Anders
>
> >
> > Cheers,
> > J.C.
> >
> > [1] https://wiki.mozilla.org/Security/CryptoEngineering#
> Web_Authentication
> > [2] https://w3c.github.io/webauthn/#android-key-attestation
> > [3] https://w3c.github.io/webauthn/#android-safetynet-attestation
> >
> > On Wed, Nov 30, 2016 at 10:54 PM, Anders Rundgren <
> > anders.rundgren@gmail.com> wrote:
> >
> > > On Wednesday, November 30, 2016 at 5:42:30 PM UTC+1, Anders Rundgren
> wrote:
> > > > It is a pity that external tokens have become the
> > > > focus when the majority will rather rely on embedded
> > > > security solutions which nowadays is a standard feature
> > > > in Android and Windows platforms.
> > >
> > > Slight clarification to the above: The IoT folks pretty much build
> 100% on
> > > embedded security with car-keys as an obvious exception.
> > >
> > > On mobile I would say that over 99% of all existing security solutions
> > > based on cryptographic keys are relying on embedded (or "App level")
> keys
> > > with Apple Pay as the most advanced example.
> > >
> > > That is, the token vendors and security folks do not represent the
> actual
> > > market comprising of end-users and service providers.
> > >
> > > Maybe this is a project primarily targeting the desktop?
> > > ___
> > > dev-platform mailing list
> > > dev-platform@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-platform
> > >
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: Use strict in function with non-simple parameters

[Tom Schuster]

To simplify parsing ES 2016 disallows "use strict" in functions with
non-simple parameters, like defaults or rest.

For example `function f(a = 1) { "use strict"; }` is going to start
throwing.

Chrome, JSC and Edge already made this change.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1272784
Link to standard:
https://tc39.github.io/ecma262/#sec-function-definitions-static-semantics-early-errors
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Moving away from autoconf

[Tom Schuster]

This is so great. Thank you!
On Feb 25, 2016 12:35 AM, "Mike Hommey"  wrote:

> Hi,
>
> We are, officially, and starting today with the landing of bug 1250294,
> moving away from autoconf. This is not going to happen overnight, and it
> is going to be painful, but the first step has just been made, and we're
> not turning back.
>
> The autoconf scripts are however still there and are used, but were
> renamed to old-configure.in. If you have pending patches against
> configure.in or js/src/configure.in, your changes will need to be
> applied to old-configure.in or js/src/old-configure.in.
>
> Cheers,
>
> Mike
> ___
> 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: Collecting web platform features implementation status

[Tom Schuster]

Seems like this kind of died. I still would like to see this happening. Is
this on somebody's agenda?

On Tue, Jul 21, 2015 at 8:40 PM, Tom Schuster <t...@schuster.me> wrote:

> I see 3 (now 4) old pull requests that are unmerged.
>
> On Tue, Jul 21, 2015 at 8:19 PM, Anthony Ricaud <anth...@ricaud.me> wrote:
>
>> On 16/07/15 21:26, Anthony Ricaud wrote:
>>
>>> Potch and I are working on a website to present Mozilla's point of view
>>> on various web platform features. Other browsers have similar websites
>>> [1] [2] [3]. This project has been in lingo for a while so, to get it
>>> out the door, we're going to focus on one information: what is Mozilla's
>>> opinion on features that have not been shipped yet. We see 4 possible
>>> answers: in development, favorable, not favorable, no opinion.
>>>
>>> In order to get accurate data and update it regularly, we need your
>>> help. Please go to the following etherpad and insert any information
>>> that can help us:
>>> https://etherpad.mozilla.org/gecko-web-platform-dashboard
>>>
>>> Thanks for your help!
>>>
>>> [1] https://www.chromestatus.com/features
>>> [2] https://status.modern.ie
>>> [3] http://www.webkit.org/status.html
>>>
>> Reminder: We need your help! Please submit a pull request against
>> https://github.com/Rik/platform-status/blob/master/features.json.
>>
>> (I've only received one pull request since moving this JSON to Github :( )
>>
>> ___
>> 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: PSA: __noSuchMethod__ is deprecated in SpiderMonkey

[Tom Schuster]

Jan just disabled __noSucnMethod__ on Nightly (Firefox 44).

On Fri, Mar 6, 2015 at 6:10 PM, Joshua Cranmer  
wrote:

> On 3/6/2015 10:44 AM, Jan De Mooij wrote:
>
>> We've deprecated [0] __noSuchMethod__ [1] support in SpiderMonkey. It's a
>> non-standard feature that no other engine supports, and it's been
>> hindering
>> ongoing performance work as __noSuchMethod__ is not trivial to support in
>> the JITs.
>>
>> I've posted patches to convert all in-tree and add-on SDK uses and we'll
>> add a console warning when __noSuchMethod__ is used [2].
>>
>> There's no drop-in replacement, but in most cases you can either use ES6
>> proxies or rewrite the code to add the properties you care about manually.
>>
>> I don't know when/if we can remove this feature from SpiderMonkey, but
>> we'll likely wait at least a few months to avoid breaking too many
>> add-ons.
>> In the meantime, please don't add or review code that uses
>> __noSuchMethod__.
>>
>
> FWIW, I've found that both the uses in comm-central are basically poor
> man's reimplementation of ES6 classes, so I don't think it's worth removing
> this code until ES6 classes land.
>
> --
> Joshua Cranmer
> Thunderbird and DXR developer
> Source code archæologist
>
>
> ___
> 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: Changes in chrome JS code due to ES6 global lexical scope

[Tom Schuster]

I think that would fail as well, because the let would be shadowing the
global x, which isn't allowed.
On Sep 18, 2015 2:25 PM, "Neil"  wrote:

> Shu-yu Guo wrote:
>
> Good catch and thanks for the correction! The take-home from the example is
>> that: due to the global lexical scope, a TDZ error could arise later due
>> to
>> newly introduced bindings.
>>
>> So for that I guess the code would have to look like this?
>
> 
> var x;
> function f() { dump(x); }
> f(); // prints undefined​
> ​
>
> 
> f(); // throws TDZ error?
> ​let x = 42;
> 
>
> --
> Warning: May contain traces of nuts.
> ___
> 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

Firefox graphics issues on Windows 10 + Firefox 40

[Tom Schuster]

Hey,

people on reddit.com/r/firefox are reporting a fair amount of graphics
related issues.
It seems like most of it boils down to newly blacklisted drivers?
Is there a bug for this somewhere?

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

Re: Firefox graphics issues on Windows 10 + Firefox 40

[Tom Schuster]

Thanks guys for fixing this.

On Thu, Aug 13, 2015 at 3:52 PM, Jeff Muizelaar jmuizel...@mozilla.com
wrote:

 AMD bug:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1189266
 Nvidia bug:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1189940

 -Jeff

 On Thu, Aug 13, 2015 at 5:22 AM, Tom Schuster t...@schuster.me wrote:
  Hey,
 
  people on reddit.com/r/firefox are reporting a fair amount of graphics
  related issues.
  It seems like most of it boils down to newly blacklisted drivers?
  Is there a bug for this somewhere?
 
  Thanks,
  Tom
  ___
  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: Feel free to use Iterator() in privileged JS (was: Re: Help with removing __iterator__ from JS)

[Tom Schuster]

Please remember that the ES6 iteration protocol can only be used with
for-of.
On Jul 28, 2015 1:20 PM, Paolo Amadini paolo.02@amadzone.org wrote:

 On 7/23/2015 4:16 PM, Boris Zbarsky wrote:

 I might be missing something, but why is __iterator__ and the
 nonstandard iteration protocol needed for this?


 It's not.

  I don't think anyone on the SpiderMonkey end particularly cares whether
 Iterator or some replacement is used.


 Thanks a lot for the clarification. I was in fact replying to Tom's
 aside of Please also try avoid using Iterator but it's clear that
 there are use cases for it and we should use it where it makes sense.

 Iterator() can even be implemented easily internally using the ES6
 iterator protocol.

 Cheers,
 Paolo
 ___
 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: Collecting web platform features implementation status

[Tom Schuster]

I see 3 (now 4) old pull requests that are unmerged.

On Tue, Jul 21, 2015 at 8:19 PM, Anthony Ricaud anth...@ricaud.me wrote:

 On 16/07/15 21:26, Anthony Ricaud wrote:

 Potch and I are working on a website to present Mozilla's point of view
 on various web platform features. Other browsers have similar websites
 [1] [2] [3]. This project has been in lingo for a while so, to get it
 out the door, we're going to focus on one information: what is Mozilla's
 opinion on features that have not been shipped yet. We see 4 possible
 answers: in development, favorable, not favorable, no opinion.

 In order to get accurate data and update it regularly, we need your
 help. Please go to the following etherpad and insert any information
 that can help us:
 https://etherpad.mozilla.org/gecko-web-platform-dashboard

 Thanks for your help!

 [1] https://www.chromestatus.com/features
 [2] https://status.modern.ie
 [3] http://www.webkit.org/status.html

 Reminder: We need your help! Please submit a pull request against
 https://github.com/Rik/platform-status/blob/master/features.json.

 (I've only received one pull request since moving this JSON to Github :( )

 ___
 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

Help with removing __iterator__ from JS

[Tom Schuster]

Hello!

We have an old JS extension that allows objects to modify how they behave
when used with for-in. However this extension will never make it into ES6
and is actually incompatible with how iteration is defined there. So please
don't use __iterator__anymore.

I would really appreciate your help with removing __iterator__ from the
OS.File interface, which makes very heavy use of this feature. Bug 938704
hasn't seen any serious work since 2013.

We also need to look into the addon-sdk, where many of the custom
collection types implement __iterator__ and thus addon authors might
iterate over them with for-in ...

Aside: Please also try avoid using Iterator().

Thank you,
Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: document.execCommand(cut/copy)

[Tom Schuster]

I think the ribbon would be really useful if it allowed the user to restore
the previous clipboard content. However this is probably not possible for
all data that can be stored in clipboards, i.e. files.

On Wed, May 6, 2015 at 7:33 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Wed, May 6, 2015 at 6:40 PM, Adam Roach a...@mozilla.com wrote:
  Going fullscreen also gives the user UI at the time of activation,
 allowing
  them to manipulate permissions in an obvious way.

 Note that we're changing that:

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


  Perhaps an analogous yellow ribbon informing the user that the site has
  copied data onto their clipboard, with buttons to allow them to prevent
 it
  from happening in the future, would be a good balance (in particular if
  denying permission restored the clipboard to its previous state) -- it
  informs the user and provides clear recourse without *requiring*
 additional
  action.

 I like this idea. Although I wonder if users will understand what is
 happening.


 --
 https://annevankesteren.nl/
 ___
 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

Resurrecting the Qt toolkit

[Tom Schuster]

Hello!

I am interested in making the Qt toolkit usable again, especially on Linux.
While I don't think we can ever actually use it for more platforms, except
maybe some mobile devices, it is still something I care about. For that
reason I am trying to avoid X11 specific code. At the moment I am mostly
making sure that --enable-default-toolkit=default-qt keeps compilable.
There have also been some patches to make key and mouse handling better,
like shortcuts. The Qt widget uses OpenGL layers by default, which works
surprisingly well. Basic layers should work on Linux, but there is some
issue with expose events. The Qt widget actually at some point support
almost all default widget features like filepickers, native themes and drag
 drop. Oleg Romashin rom...@gmail.com had to remove these features to
make to code compile with Qt 5. (
https://hg.mozilla.org/mozilla-central/rev/c5953f75569b) So most of the
things that are currently missing actually existed at one point and just
have to be reimplemented.
Right now my focus is on fixing the different kind of bounds, positions,
move and resize operation on the window. After that I will probably look
into native themes. There has been some discussion recently about KDE
integration, which makes me hope that maybe some of them would be
interested in helping out. I am actually quite new to Qt, but I find it a
lot easier to handle than GTK. There seems to be also a recent shift of
some apps to Qt as well.

Maybe somebody is interested in this project? Here is a screenshot that I
tweeted a while ago: https://pbs.twimg.com/media/BrFDppxCIAEeZr9.png:large

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

Re: Overriding the CSP for privileged protocols

[Tom Schuster]

Sounds like you would use nsIDOMWindowUtils.loadSheet for that.

-Tom


On Sat, Jun 7, 2014 at 8:27 PM, L. David Baron dba...@dbaron.org wrote:

 On Friday 2014-06-06 00:30 -0700, Matthew Gertner wrote:
  As things stand, it should be possible for responsible extensions such
 as ours (we implement our own nsIContentPolicy for our protocol) to do
 things like inject CSS into pages.

 We should probably have mechanisms for addons to inject CSS into
 pages without having to insert a link into the document, though.

 Injecting link elements can be observed by the page, could break
 page script (I've seen scripts looking for the first/last style
 sheet link to add a rule to it), and can presumably be undone by the
 page if it wants to break the addon.

 Having a more distinct mechanism for this might avoid these CSP
 issues.

 -David

 --
 턞   L. David Baron http://dbaron.org/   턂
 턢   Mozilla  https://www.mozilla.org/   턂
  Before I built a wall I'd ask to know
  What I was walling in or walling out,
  And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

 ___
 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: Google announces Chrome builds for Win64

[Tom Schuster]

 - Add-ons are going to break in both projects. We need to take the
developer community's pain into consideration.
What is the problem with addons and win64, binary addons? For e10s JS-only
addons are problematic as well, so the level of problems we can expect here
are quite different.

I don't think we should block win64 on e10s, because even estimating when
the project is going to ship to end-users is hard.

Cheers,
Tom


On Wed, Jun 4, 2014 at 8:07 PM, jmor...@mozilla.com wrote:

 Great point Brian, I should've mentioned the relation to E10S and
 sandboxing because as you suggest, it's complicated.

 - E10S and sandboxing help 32 bit users as well as 64 and arguably offer
 the most immediate relief to the most users experiencing stability issues.
 Most of the folks I spoke with recommended tackling both of those before 64
 if it comes to that.

 - E10S and sandboxing are also more complicated and have a much longer
 time horizon to launch. Launching 64 bit first may be a stability bandaid
 for users who have 64 bit and adequate memory. It's also security boost for
 64 bit users.

 - Plugin work, as BDS says, is hard and weird. E10S and 64 compete for
 the same engineers here.

 - Add-ons are going to break in both projects. We need to take the
 developer community's pain into consideration.

 Those are some big considerations to weigh in resource planning, product,
 developer community, and especially in engineering. This feels like the
 start of that conversation...





 On Wednesday, June 4, 2014 1:32:48 PM UTC-4, Brian Smith wrote:
  On Tue, Jun 3, 2014 at 11:37 AM, Chris Peterson
 
  wrote:
 
 
 
   http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-
 
   canary-and.html
 
  
 
   What is the status of Firefox builds for Win64? When Mozilla releases
 
   Win64 builds (again), we'll be seen as reacting to Google when we've
 
   actually been working on it for a while. :\
 
  
 
 
 
  Does it make sense to ship 64-bit Firefox before shipping
 
  mutli-process/sandboxed Firefox? I worry that 64-bit Firefox will be more
 
  memory hungry than 32-bit Firefox and if it lands first then it will be
 
  harder to land multi-process Firefox which is also likely to use more
 
  memory. I think having multi-process sooner is more important than having
 
  64-bit sooner, if there is such a choice to make. IMO, it would be good
 to
 
  make explicit choices instead of just shipping whichever is done first.
 
 
 
  Cheers,
 
  Brian

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

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

Re: Intent to implement and ship: navigator.hardwareConcurrency

[Tom Schuster]

I recently saw this bug about implementing navigator.getFeature, wouldn't
it make sense for this to be like hardware.memory, but hardware.cores?


On Tue, May 13, 2014 at 6:25 PM, Rik Cabanier caban...@gmail.com wrote:

 On Tue, May 13, 2014 at 8:20 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
 wrote:

  On Tue, May 13, 2014 at 2:37 AM, Rik Cabanier caban...@gmail.com
 wrote:
 
  On Mon, May 12, 2014 at 10:15 PM, Joshua Cranmer  
 pidgeo...@gmail.com
  wrote:
 
   On 5/12/2014 7:03 PM, Rik Cabanier wrote:
  
   *Concerns*
  
   The original proposal required that a platform must return the exact
   number
   of logical CPU cores. To mitigate the fingerprinting concern, the
  proposal
   was updated so a user agent can lie about this.
   In the case of WebKit, it will return a maximum of 8 logical cores so
  high
   value machines can't be discovered. (Note that it's already possible
  to do
   a rough estimate of the number of cores)
  
  
   The discussion on the WHATWG mailing list covered a lot more than the
   fingerprinting concern. Namely:
   1. The user may not want to let web applications hog all of the cores
  on a
   machine, and exposing this kind of metric makes it easier for
  (good-faith)
   applications to inadvertently do this.
  
 
  Web applications can already do this today. There's nothing stopping
 them
  from figuring out the CPU's and trying to use them all.
  Worse, I think they will likely optimize for popular platforms which
  either
  overtax or underutilize non-popular ones.
 
 
  Can you please provide some examples of actual web applications that do
  this, and what they're exactly trying to do with the number once they
  estimate one?  (Eli's timing attack demos don't count. ;-)
 

 Eli's listed some examples:
 http://wiki.whatwg.org/wiki/NavigatorCores#Example_use_cases
 I don't have any other cases where this is done. Maybe PDF.js would be
 interested. They use workers to render pages and decompress images so I
 could see how this is useful to them.


   2. It's not clear that this feature is necessary to build high-quality
   threading workload applications. In fact, it's possible that this
  technique
   makes it easier to build inferior applications, relying on a
 potentially
   inferior metric. (Note, for example, the disagreement on figuring out
  what
   you should use for make -j if you have N cores).
 
 
  Everyone is in agreement that that is a hard problem to fix and that
 there
  is no clear answer.
  Whatever solution is picked (maybe like Grand Central or Intel TBB),
 most
  solutions will still want to know how many cores are available.
  Looking at the native platform (and Adobe's applications), many query
 the
  operating system for this information to balance the workload. I don't
 see
  why this would be different for the web platform.
 
 
  I don't think that the value exposed by the native platforms is
  particularly useful.  Really if the use case is to try to adapt the
 number
  of workers to a number that will allow you to run them all concurrently,
  that is not the same number as reported traditionally by the native
  platforms.
 

 Why not? How is the web platform different?


  If you try Eli's test case in Firefox under different workloads (for
  example, while building Firefox, doing a disk intensive operation, etc.),
  the utter inaccuracy of the results is proof in the ineffectiveness of
 this
  number in my opinion.
 

 As Eli mentioned, you can run the algorithm for longer and get a more
 accurate result. Again, if the native platform didn't support this, doing
 this in C++ would result in the same.


  Also, I worry that this API is too focused on the past/present.  For
  example, I don't think anyone sufficiently addressed Boris' concern on
 the
  whatwg thread about AMP vs SMP systems.
 

 Can you provide a link to that? Are there systems that expose this to the
 user? (AFAIK slow cores are substituted with fast ones on the fly.)


  This proposal also assumes that the UA itself is mostly contempt with
  using a single core, which is true for the current browser engines, but
  we're working on changing that assumption in Servo.  It also doesn't take
  the possibility of several ones of these web application running at the
  same time.
 

 How is this different from the native platform?


  Until these issues are addressed, I do not think we should implement or
  ship this feature.
 

 FWIW these issues were already discussed in the WebKit bug.
 I find it odd that we don't want to give authors access to such a basic
 feature. Not everything needs to be solved by a complex framework.
 ___
 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: DXR UI refresh is live!

[Tom Schuster]

The design looks really fresh, I really like the new colors. I am however
wondering about additional spaces that were introduced, they seem to even
break indentation:
http://dxr.mozilla.org/mozilla-central/source/js/src/jsapi.cpp#1426.

-Tom


On Sat, Feb 8, 2014 at 1:29 AM, Erik Rose e...@mozilla.com wrote:

  that's pretty, but where did the list of classes  class members go when
 viewing files like
 http://dxr.mozilla.org/mozilla-central/source/modules/libjar/nsZipArchive.cpp

 Coming back soon: https://bugzilla.mozilla.org/show_bug.cgi?id=965659.
 We're having some trouble reducing it to a test case smaller than
 moz-central.

 ___
 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: Toolkit sub-module Preferred Reviewers who are not Toolkit Peers

[Tom Schuster]

I refactorted and debugged most of the findbar code. Mike seems to the de
facto owner, so I think it makes sense for me to do reviews. I doubt
anybody else knows much about the code. There seems to be no submodule for
it anyway?
On Jan 19, 2014 10:40 PM, Matthew N. ma...@mozilla.com wrote:

 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. ma...@mozilla.com 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

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

Re: Mozilla style guide issues, from a JS point of view

[Tom Schuster]

I don't use Terminals for programming, I have the space for 100 chars. I
also usually don't open more than one window at a time. I usually just
switch between files very quickly if I need to correlate something.
Everytime single time I create a patch that touches a lot of code Gecko, I
feel like 80 chars is just not enough. My experience is obviously kind of
skewed, because I mostly edit function definitions in away that makes them
longer, i.e. replace JS::Value with JS::HandleJS::Value. I feel like a
thousand times I just barely miss the 80 char limit and I have to start
wrapping some arguments around, which can be really annoying, because
suddenly you also have to move something else etc.

I don't really care about 2/4 spaces, I just press tab anyway.


On Fri, Jan 17, 2014 at 3:03 AM, gokoproj...@gmail.com wrote:

 re 80char vs 100chars:

 I am for 80 chars.

 If the argument for expanding to 100 or more is that screen is getting
 wider, then the benefit of wide screen is able to fit multiple terminals in
 one window. For normal workflow, I'd split my windows into two or
 terminals, depending on what I am doing, so I don't see any benefit for
 increasing the limit.


 re braces for single statement:

 I am for always braces.

 If multi-statement logical statement requires braces pair, why make
 exception to the single logical branch?

 if (...)
   do_stuff

 vs

 if (...) {
   do_stuff
 }

 and if I need to add more statements (like adding debug), I don't need to
 go back and add { } again which can be as difficult as adding { } in the
 first place (but that's a one-time cost). I am not sure why this is not a
 problem... I know, it sounds lazy, but since we are mentioning
 productivity


 re 2 spaces vs 4 spaces:

 I'd keep with two-space.

 I come from Python world and after working on Firefox for a while I am
 used to two-space instead of four-space in Firefox.

 Does four-space increase productivity? My take on this is that not
 necessarily and productivity depends on the tool the developer is using. If
 you use vim you can set the tab indentation to four spaces. You can also
 set language-specific indentation. I can't speak of other editors and IDEs
 out there and we certainly can't make everyone happy.

 Chromium has the following style guide:

 Python code should follow PEP-8, except that Chromium uses two-space
 indentation instead of four-space indentation, and it uses MixedCase for
 method names and function names instead of lower_case_with_underscores

 I am not saying we have to stick with two-space because Chromium uses
 two-space since Linux kernel is 8-space, but two-space is not rare at all
 (I am not sure Chromium's decision is influenced by people who started
 Chrome in the first place, as they had/have been firefox contributors).

 Finally, another thing to consider when we write a style checker is to
 consider this way of wrapping lines:

 const SOME_REGEX_CONSTANT = new RegExp(^(str1|str2 +
str3|str4);

 const SOME_KEYWORD_TO_SET = hello world +
 what is going on?


 ___
 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: How to create a child process in a chrome mochitest?

[Tom Schuster]

Here is the CPOW test that creates a remote browser:
http://mxr.mozilla.org/mozilla-central/source/content/base/test/chrome/test_cpows.xul


On Fri, Sep 6, 2013 at 9:41 AM, Neil n...@parkwaycc.co.uk wrote:

 Nicholas Nethercote wrote:

  In theory, this is as easy as iframe mozbrowser remote or browser
 remote, or something like that.  But I've tried about 80 different
 variations on these, and I cannot get a child process.

  Mochitests already run inside a browser, so attempting to nest a child
 browser will fail. Try opening a chrome window with a XUL document
 containing a remote browser element.

 --
 Warning: May contain traces of nuts.

 __**_
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/**listinfo/dev-platformhttps://lists.mozilla.org/listinfo/dev-platform

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

Re: reminder: content processes (e10s) are now used by desktop Firefox

[Tom Schuster]

Do we run JS code in these? I can imagine all sorts of things that
would cause a crash if JS code can invoke random dom apis. I however
very happy that we are testing browser remote=true in a limited
fashion with this.

Tom

On Tue, Jul 30, 2013 at 7:10 PM, Gavin Sharp ga...@gavinsharp.com wrote:
 I've mentioned this at the engineering meeting, but thought it worth a note
 here just to ensure everyone is aware:

 Bug 870100 enabled use of the background thumbnail service in Firefox
 desktop, which uses a browser remote=true to do thumbnailing of pages in
 the background.

 That means that desktop Firefox now makes use of E10S content processes.
 They have a short life time (one page load) and are generally triggered by
 opening about:newtab when thumbnails are missing or out of date (2 days
 old).

 This has exposed some e10s crashes that previously weren't exposed on
 desktop. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=899758 to
 track them - please hang any other such crashes off that bug. If you're
 working in a component that has e10s-related crashes, please fix them :)

 (Bug 891218 is also planning to make use of content processes for some
 Social-related functionality. Those remote processes will be longer-lived,
 typically having the same lifetime as the parent process.)

 Gavin

 ___
 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: Accelerating exact rooting work

[Tom Schuster]

At the moment it's really just Jono working full time on this, and
terrence and other people reviewing. This stuff is actually quite easy
and you can expect really fast review times from our side.

In some parts of the code rooting could literally just mean to replace
JS::Value to JS::RootedValue and fixing the references to the
variable. It's really easy once you did it a few times.

Here is a list of all files that still have rooting problems:
http://pastebin.mozilla.org/2340241
And the details for each and every problem:
https://people.mozilla.com/~sfink/analysis/browser/rootingHazards.txt

We are using https://bugzilla.mozilla.org/show_bug.cgi?id=831379 to
track the rooting progress, make sure to file every bug as blocking
this one. I would appreciate if every module peer or owner would just
take a look at his/her module and tried to fix some of the issue. If
you are unsure or need help, ask us on #jsapi.

Thanks,
Tom

On Tue, Apr 23, 2013 at 3:03 AM, Robert O'Callahan rob...@ocallahan.org wrote:
 On Tue, Apr 23, 2013 at 5:36 AM, Terrence Cole tc...@mozilla.com wrote:

 Our exact rooting work is at a spot right now where we could easily use
 more hands to accelerate the process. The main problem is that the work
 is easy and tedious: a hard sell for pretty much any hacker at mozilla.


 It sounds worthwhile to encourage developers who aren't currently working
 on critical-path projects to pile onto the exact rooting project. Getting
 GGC over the line reaps some pretty large benefits and it's an
 all-or-nothing project, unlike say pursuing the long tail of WebIDL
 conversions.

 If that sounds right, put out a call for volunteers (by which I include
 paid staff) to help push on exact rooting, with detailed instructions. I
 know some people who could probably help.

 Rob
 --
 q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
 qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
 qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
 qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q
 qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
 qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q
 ___
 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: Accelerating exact rooting work

[Tom Schuster]

You wont have to bother with HandleObject or RootedObject etc. These
are internal to js/ and we take care of these cases.  Just use
JS::HandleJSObject* or JS::RootedJSObject*. Thanks for pointing
people to this file.

PS: The correct handle for Jon Coppeard is of course jonco!

On Tue, Apr 23, 2013 at 3:58 PM, smaug sm...@welho.com wrote:
 On 04/23/2013 04:07 PM, Tom Schuster wrote:

 At the moment it's really just Jono working full time on this, and
 terrence and other people reviewing. This stuff is actually quite easy
 and you can expect really fast review times from our side.

 In some parts of the code rooting could literally just mean to replace
 JS::Value to JS::RootedValue and fixing the references to the
 variable. It's really easy once you did it a few times.

 Here is a list of all files that still have rooting problems:
 http://pastebin.mozilla.org/2340241
 And the details for each and every problem:
 https://people.mozilla.com/~sfink/analysis/browser/rootingHazards.txt

 We are using https://bugzilla.mozilla.org/show_bug.cgi?id=831379 to
 track the rooting progress, make sure to file every bug as blocking
 this one. I would appreciate if every module peer or owner would just
 take a look at his/her module and tried to fix some of the issue. If
 you are unsure or need help, ask us on #jsapi.

 Thanks,
 Tom


 I found http://mxr.mozilla.org/mozilla-central/source/js/public/RootingAPI.h
 quite useful, but there are few things to
 clarify. For example some code uses HandleObject and some code
 HandleJSObject* and having two ways to do the same thing
 just makes the code harder to read.


 On Tue, Apr 23, 2013 at 3:03 AM, Robert O'Callahan rob...@ocallahan.org
 wrote:

 On Tue, Apr 23, 2013 at 5:36 AM, Terrence Cole tc...@mozilla.com wrote:

 Our exact rooting work is at a spot right now where we could easily use
 more hands to accelerate the process. The main problem is that the work
 is easy and tedious: a hard sell for pretty much any hacker at mozilla.


 It sounds worthwhile to encourage developers who aren't currently working
 on critical-path projects to pile onto the exact rooting project. Getting
 GGC over the line reaps some pretty large benefits and it's an
 all-or-nothing project, unlike say pursuing the long tail of WebIDL
 conversions.

 If that sounds right, put out a call for volunteers (by which I include
 paid staff) to help push on exact rooting, with detailed instructions. I
 know some people who could probably help.

 Rob
 --
 q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q
 qwqhqaqtq
 qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
 qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
 qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq
 qyqoquq,q
 qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
 qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q
 ___
 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: JavaScript reference changes: looking for opinions

[Tom Schuster]

I agree, it is also super tedious to set up and update. You always
have to remember to go to /prototype and sometimes you need to clear
the caching of the pages that include it. I think some these pages
sometimes have extra information that is not included in the main
page, but I doubt many people even look there. When I created
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/ParallelArray,
I also didn't bother to create the prototype page.


On Mon, Apr 22, 2013 at 9:04 PM, Eric Shepherd esheph...@mozilla.com wrote:
 Currently, the JavaScript reference content for the global classes (String,
 Array, etc), are divided up such that the class methods and properties and
 the prototype methods and properties are documented separately, with links
 between them. For example, see:

 https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/String

 and

 https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/String/prototype

 While this might make sense to super-expert JavaScript folks (indeed, it was
 their idea to do it this way), it's actually really confusing to everyone
 else.

 I'd like to propose we merge them back together, so that the stuff currently
 documented on the prototype page is in the main body of the class's
 documentation where most people would expect it to be. If useful, we can
 come up with a badge to put next to items that are part of the prototype (or
 not) to differentiate between them.

 But the current organization is, well, kind of weird.

 Any opinions on this pro or con before we actually try to find someone to do
 the work?

 --
 Eric Shepherd
 Developer Documentation Lead
 Mozilla
 Blog: http://www.bitstampede.com/
 Twitter: @sheppy

 ___
 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