Re: Intent to prototype: re-enabling SharedArrayBuffer

[J. Ryan Stinnett]

On Thu, 29 Aug 2019 at 12:48, Anne van Kesteren  wrote:
> Note that SharedArrayBuffer itself is already enabled by default as
> ECMAScript (JavaScript) was never changed. And that standard requires
> a host to allow cross-thread usage as while it describes
> infrastructure for threads (agents) it doesn’t provide access to them
> without a host.

Thanks for writing up this comprehensive intent notice. I am having
trouble parsing this part though... You say that "SharedArrayBuffer
itself is already enabled by default", but as far as I can tell, at
the moment it is still controlled by the pref
"javascript.options.shared_memory", which is false by default.
Checking in the console, SAB doesn't seem to be available in stock
Nightly, so I am a bit confused as to what the current status is.

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

Re: What is dom/browser-element/ used for?

[J. Ryan Stinnett]

Yes, it's currently used for Responsive Design Mode in DevTools. I believe
that is the only place it's used in the tree today.

- Ryan

On Thu, 28 Feb 2019 at 12:24, Henri Sivonen  wrote:

> I think I found a user in dev tools:
>
> https://searchfox.org/mozilla-central/rev/2a6f3dde00801374d3b2a704232de54a132af389/devtools/client/responsive.html/components/Browser.js#140
>
> On Thu, Feb 28, 2019 at 11:45 AM Henri Sivonen 
> wrote:
> >
> > It appears dom/browser-element/ was created for Gaia. Is it used for
> > something still? WebExtensions perhaps?
> >
> > --
> > Henri Sivonen
> > hsivo...@mozilla.com
>
>
>
> --
> 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

Re: mozilla-central Fails to Build on Mac With Latest Xcode (10.0)

[J. Ryan Stinnett]

The Xcode 10 Release Notes[1] in the "Command Line Tools" heading suggests
that future versions will not provide a *.pkg to install headers to
/usr/include, so we may want to adjust whichever build steps depend on this
location.

[1]:
https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes

- Ryan

On Tue, Sep 25, 2018 at 2:04 PM Miko Mynttinen 
wrote:

> Some of those people (like me) who were eager to use Dark Mode might now
> have trouble building Firefox.
>
> This is because Mojave update removes system headers from /usr/include.
> They can be restored by installing Xcode command line tools and the headers
> that come bundled with them.
>
> Instructions for Xcode 10:
>
> 1) Install Xcode command line tools
> $ xcode-select --install
>
> 2) Install the bundled system headers
> $ open
> /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
>
>
>
> Miko
>
>
> > On Sep 19, 2018, at 8:06 PM, Haik Aftandilian 
> wrote:
> >
> > This has been resolved. The fix for bug 1492210 is now in
> mozilla-central,
> > thanks to Miko.
> >
> > Haik
> >
> > On Tue, Sep 18, 2018 at 11:30 AM Haik Aftandilian <
> haftandil...@mozilla.com>
> > wrote:
> >
> >> If you don't build on macOS, read no further.
> >>
> >> With the latest XCode (10.0) just released, mozilla-central fails to
> build
> >> due to bug 1492210 "nsCocoaUtils.mm compile error on macOS 10.13 with
> >> 10.14 SDK" [1]. I recommend avoiding installing the new XCode until we
> >> have this fixed. If you've configured your builds to use an older SDK
> and
> >> not the default XCode install, you will not be affected.
> >>
> >> Haik
> >>
> >> 1. https://bugzilla.mozilla.org/show_bug.cgi?id=1492210
> >>
> >>
> > ___
> > 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 move Activity Stream into its own process

[J. Ryan Stinnett]

On Mon, Jun 18, 2018 at 3:20 PM Gijs Kruitbosch 
wrote:

> If it *would* mean a process switch, we may want to take another look at
> some of the bugs relating to those (process switches are currently
> relatively rare) and re-prioritize them.
>

I am not sure about the specific AS work here, but for the general case, I
believe that Fission intends to cause a process switch anytime a tab
navigates to an unrelated origin, so this will also increase the frequency
of process switching.

So, it would seem that any issues around process switching would be good to
triage again, either because of the AS work or the more general Fission
plans.

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

Feature Removed: View Source in new window

[J. Ryan Stinnett]

(My apologies for not sending an Intent to Unship in advance.)

In bug 1418403, the (disabled by default) ability to have View Source open
in its traditional separate window was removed. Instead, View Source now
always opens in new browser tab.

Telemetry was collected[1] back in 2015 to see who was choosing to revert
to the window mode. This showed that 0.62% of View Source uses went to the
window mode. (There has never being any UI to choose, so you would have to
have known about the pref to revert to window mode.)

In recent weeks, the View Source window became a blocker of the work to
remove XBL, as it used several bindings. Given this information in
combination with the low usage, we felt it was time to remove the View
Source window.

If the separate View Source window was important to you, there are several
options available. The View Source in external editor mode is one
alternative (see prefs view_source.editor.*) that works today. Bug 1444133
has also been filed to offer the newer tab-based UI but opened in a
separate browser window instead of a tab in the same window.

If the above workarounds are important to you or if you believe something
else is needed, please let me know here or elsewhere so that it can be
prioritized.

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

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

Re: Intent to unship: "storage" attribute in options for indexedDB.open()

[J. Ryan Stinnett]

DevTools is one chrome caller that might be impacted. We craft a custom
principal and pass `storage: persistent`[1] when using IndexedDB in the
tools.

DevTools uses this storage for developer settings that should be retained
over time. It sounds like with the proposed change here, DevTools storage
might lose the persistent status. If that's true, what's the right approach
to maintain the status quo? I don't think it makes sense to show a
permission prompt when DevTools access its storage, since it is a browser
feature.

Should we add an exception for the DevTools iDB principal? Should DevTools
use the system principal and migrate existing data?

[1]:
https://searchfox.org/mozilla-central/rev/bffd3e0225b65943364be721881470590b9377c1/devtools/shared/indexed-db.js#34

- Ryan

On Tue, Mar 6, 2018 at 9:58 AM, Johann Hofmann  wrote:

> I would like to unship the proprietary "storage" attribute in
> indexedDB.open()[0]. It allows developers to prevent their indexedDB
> storage from being evicted as part of quota management[1]. However,
> there is a web standard which specifies a better persistent storage
> mechanism and has broader vendor support[2].
>
> There are several issues with the old proprietary version:
>
> - It's only supported by Firefox.
> - It can be used over insecure HTTP, which is against the persistent
> storage spec.
> - Its internal mechanism is only concerned with indexedDB and does not
> integrate with other quota managed storage.
> - We actually need to maintain two separate permissions that do more or
> less the same thing ("indexedDB" and "persistent-storage"). The UI for
> managing these looks almost exactly the same and it's impossible to
> clarify the difference. It's a pretty annoying security/privacy UX issue
> and difficult to justify to users.
>
> The plan is to ignore the "storage" attribute and label all databases
> opened from iDB.open as default (i.e. dependent on the persistent
> storage mechanism).
>
> Before doing this, we will issue a deprecation warning in the browser
> console and write a blog post on Mozilla Hacks. Affected websites could
> lose their indexedDB data (equivalent to the user clearing their
> cookies), unless they migrate to the new storage model.
>
> We are tracking this work in bug 1354500
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1354500).
>
> We have seen very low usage on beta[3], with the exception of a spike in
> November which we attribute to about:home usage from a/b testing. After
> we stopped counting usage from about: pages on Nightly, the telemetry
> probe stopped signaling completely[4].
>
> I personally consider these numbers (prior to any evangelism or console
> warnings) low enough to unship within the Firefox 62 timeframe, without
> migration.
>
> Chrome callers should not be affected by this, since we upgrade the
> system principal to persistent storage automatically.
>
> Please let me know what you think.
>
> Thanks,
>
> Johann
>
> [0] https://developer.mozilla.org/en-US/docs/Web/API/IDBFactory/
> open#Syntax
> [1]
> https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_
> API/Browser_storage_limits_and_eviction_criteria
> [2] https://storage.spec.whatwg.org/
> [3] https://mzl.la/2GVyQ7g
> [4] https://mzl.la/2FqW0FH
> ___
> 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: Retained Display Lists

[J. Ryan Stinnett]

How is the AIL metric defined? I looked around Hasal for a bit, but I
didn't see a clear definition.

Is it similar to RAIL[1], or something entirely different?

[1]: https://developers.google.com/web/fundamentals/performance/rail

- Ryan

On Tue, Oct 31, 2017 at 5:23 AM, Shako Ho  wrote:

> Hi Matt,
>
>   We just re-run the Hasal against the latest nightly with
> layout.display-list.retain=true,
>
>   and you can see the detail report as below:
>
> https://gist.github.com/ShakoHo/f9a654e327ee9dfa499584a8eeb27b7a
>
>  Summary:
>
>- 60% of test cases(12/20) indicate AIL time improved on this testing
>target build
>- The test cases listed below show significant improvement ail time
>-
>   - test_firefox_amazon_ail_hover_related_product_thumbnail
>-
>   - test_firefox_facebook_ail_click_open_chat_tab
>-
>   - test_firefox_gmail_ail_open_mail
>
> Feel free to ask if there is any question
> Regards,
> Shako
>
> --
> Senior Software Engineer,
> Firefox Mozilla
>
> On Tue, Oct 31, 2017 at 6:16 PM, Kan-Ru Chen  wrote:
>
> > Looks good!
> >
> > Could you share this to the other mail list? Thanks!
> >
> > Kanru
> >
> >
> > On Tue, Oct 31, 2017, at 05:43 PM, Shako Ho wrote:
> >
> > Hi Kan-Ru,
> >
> >   Please check the detail report below:
> >
> > https://gist.github.com/ShakoHo/f9a654e327ee9dfa499584a8eeb27b7a
> >
> >   Summary:
> >
> >- 60% of test cases(12/20) indicate AIL time improved on this testing
> >target build
> >- The test cases listed below show significant improvement ail time
> >-
> >   - test_firefox_amazon_ail_hover_related_product_thumbnail
> >   -
> >   - test_firefox_facebook_ail_click_open_chat_tab
> >   -
> >   - test_firefox_gmail_ail_open_mail
> >
> >
> > --
> > Senior Software Engineer,
> > Firefox Mozilla
> >
> > On Mon, Oct 30, 2017 at 5:29 PM, Kan-Ru Chen  wrote:
> >
> > RDL is in Nightly now. Time to test again?
> >
> > Kanru
> >
> > - Original message -
> > From: mwood...@mozilla.com
> > To: dev-platform@lists.mozilla.org
> > Subject: Re: Intent to ship: Retained Display Lists
> > Date: Wed, 25 Oct 2017 21:13:14 -0700 (PDT)
> >
> > On Monday, October 9, 2017 at 1:22:55 PM UTC+13, Matt Woodrow wrote:
> >
> > >
> > > We're planning on landing the code for retaining display lists in 58,
> > > behind the pref layout.display.list.retain.
> > >
> >
> > This has now landed in Nightly, and looks to be working really well.
> >
> > We'd really appreciate some early feedback, so feel free to set
> > layout.display-list.retain=true and give it a try!
> >
> > Please file bugs blocking 1352499 if you find any issues.
> >
> > Thanks!
> >
> >  - Matt
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "hasal-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to hasal-dev+unsubscr...@mozilla.com.
> > To post to this group, send email to hasal-...@mozilla.com.
> > To view this discussion on the web visit https://groups.google.com/a/mo
> > zilla.com/d/msgid/hasal-dev/1509355750.2035304.1155294128.4C
> > 0C7C44%40webmail.messagingengine.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

Re: We need better canaries for JS code

[J. Ryan Stinnett]

This may not be what you want here, but just so you are aware of the
option...

You can use `Services.console.registerListener`[1] in a test harness, etc.
to hear messages logged to the console. The harness could count messages of
a certain type (like script errors) and fail the test if there's an
unexpected count (similar to assertion handling in some harnesses).

Some test harnesses already register console listeners, but many of them
just echo the messages to the test log without examining them further.

For JS errors logged to the console, you can QI them to nsIScriptError and
examine more details like line, column, stack, etc.

Anyway, might not cover all the cases envisioned here, but it's one tool
available to us.

[1]:
http://searchfox.org/mozilla-central/search?q=console.registerListener&case=true®exp=false&path=

- Ryan

On Wed, Oct 18, 2017 at 6:51 AM, Mark Banner  wrote:

> Looping in firefox-dev as well, as I thin this is an important discussion.
>
> On 18/10/2017 09:28, David Teller wrote:
>
> Hi everyone,
>
>   Yesterday, Nightly was broken on Linux and MacOS because of a typo in
> JS code [1]. If I understand correctly, this triggered the usual
> "undefined is not a function", which was
>
> 1/ uncaught during testing, as these things often are;
>
> Part of the reason it was uncaught, is that there's no automated test
> coverage for that bit of code. It is a migration from one version to the
> other, but unless there is an explicit test (and I don't see one) that line
> won't be hit.
>
> This seems to be a common theme with various migration routes in the code
> base, when I've asked about ensuring more automated testing there before I
> feel like I've got shrugs.
>
> Admittedly, a lot of it is simple code, and should be correct, but as
> we've seen, mistakes can be made. Should we now be changing our policy?
>
> At a minimum, I wonder if we could write some sort of simple test for
> CustomizableUI that would go through most routes (with minimal updates for
> each change).
>
> 2/ basically impossible to diagnose in the wild, because there was no
> error message of any kind.
>
> I did an experiment, and the only way I got an error out was to have
> "javascript.options.strict" on and "browser.dom.window.dump.enabled".
> Unfortunately the breakage was such that the browser console couldn't be
> opened, so you'd just having strict on wasn't enough.
>
> 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.
>
> ESLint has caught some bugs - mainly undefined and unused related issues,
> and is spread through most of the production javascript code. Unfortunately
> it isn't able to catch this class of error. For that, we'd need something
> like Flow. Last time I looked at it, it didn't feel like a good fit for us,
> although I didn't go too deep, and I think there may have been other people
> that were looking at it.
>
> 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.
>
> It would definitely be interesting to fail tests on some of the strict
> failures. I was surprised when I recently turned on the pref again to see
> how many warnings there were.
>
> Having looked through a few of those, I've just found at least one issue
> , though
> non-critical, and I'm thinking we want to get the no-unused-expressions
>  rule turned on for
> ESLint as a result.
>
> Mark
>
> ___
> 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: Canonical cinnabar repository

[J. Ryan Stinnett]

There are also some details about MozReview with git-cinnabar at:

http://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview/install-git.html

though it doesn't seem to appear in the contents sidebar on the left, so it
would be nice to make it more discoverable. (Though I suppose Phabricator
will be the tool we use soonish...)

- Ryan

On Wed, Sep 20, 2017 at 12:04 PM, Jeff Muizelaar 
wrote:

> I would recommend
> https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-
> git-workflow-for-Gecko-development.
>
> The other places should probably be updated to point at that.
>
> -Jeff
>
> On Wed, Sep 20, 2017 at 12:57 PM, Ethan Glasser-Camp
>  wrote:
> > Sorry if this is a bit off-topic. It seems from these threads that there
> is
> > a more-or-less canonical way to use git to hack on Firefox. Where can I
> > find out more about it?
> >
> > Looking online, the only information I could find was at
> > https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-
> git-workflow-for-Gecko-development.
> > Is that the best source of information? I didn't see anything under
> > https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide,
> > http://mozilla-version-control-tools.readthedocs.io/en/latest/, or
> > https://firefox-source-docs.mozilla.org/.
> >
> > Thanks!
> >
> > Ethan
> >
> >
> > On Mon, Sep 18, 2017 at 10:05 AM, Kartikaya Gupta 
> > wrote:
> >
> >> This message was inspired by the `mach try` thread but is off-topic
> >> there so I think deserves its own thread.
> >>
> >> It seems to me that a lot of people are now assuming a cinnabar repo
> >> is the canonical way for git users to develop on mozilla-central. If
> >> we want to make this mozilla policy I don't really have objections,
> >> but I think that if we do that, we should maintain a canonical git
> >> repo that is built using cinnabar, rather than having everybody have
> >> their own "grafted" version of a cinnabar repo. The problem with the
> >> latter approach is that different people will have different SHAs for
> >> the same upstream commit, thus making it much harder to share repos.
> >>
> >> I've tried using cinnabar a couple of times now and the last time I
> >> tried, this was the dealbreaker for me. My worfklow often involves
> >> moving a branch from one machine to another and the extra hassle that
> >> results from mismatched SHAs makes it much more complicated than it
> >> needs to be. gecko-dev doesn't have this problem as it has a canonical
> >> upstream that works much more like a regular git user expects.
> >>
> >> As an aside, I also think that the cinnabar workflow as it exists now
> >> actually demotes git to more of a "second-class citizen".
> >> Conceptually, if you're using gecko-dev, everything works exactly as a
> >> git user would expect, and only when you need to push to official
> >> mozilla hg repos do you need to overcome the vcs translation hurdle
> >> (which things like moz-git-tools help with). However if you use
> >> cinnabar the vcs translation is more woven into your everyday git
> >> commands (e.g. git pull) and you need to be more consciously aware of
> >> it. This makes it harder to use whatever your normal git workflow is,
> >> which is why I claim it demotes git to second-class. It would be great
> >> if we could come up with a way to avoid this but honestly since I
> >> haven't used a cinnabar workflow for any significant period of time I
> >> haven't given much thought as to how to go about doing this.
> >>
> >> Discussion welcome!
> >>
> >> Cheers,
> >> kats
> >> ___
> >> 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

Stylo now the default configuration for mozilla-central

[J. Ryan Stinnett]

Assuming bug 1330412 sticks, Stylo will be the default configuration for
mozilla-central for all platforms except Android.  Thanks to everyone
involved with Stylo that helped us reach this stage!

Nightly users should not notice much change, since there was already an
active experiment that enabled Stylo for most of the Nightly population.

To ensure the old style system remains functional as a fallback,
separate "Stylo
disabled" test platforms have been added. We will also have a small subset
of the population using the old style system via experiments.

As always, if you encounter any issues that could be Stylo related, you can
check Stylo status in about:support.  Please file a bug[1] in Core :: CSS
Parsing and Computation with "Stylo: " in the subject, or stop by #servo on
IRC.

[1]:
https://bugzilla.mozilla.org/enter_bug.cgi?component=CSS%20Parsing%20and%20Computation&product=Core&short_desc=Stylo%3A%20

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

Rust logging with e10s

[J. Ryan Stinnett]

If you've used RUST_LOG to enable logging for Rust modules, but were hoping
you could filter down to child processes only, bug 1390736 now allows you
to use RUST_LOG_CHILD to target them. This has been helpful for several of
us working on Stylo.

To use, just replace RUST_LOG with RUST_LOG_CHILD and supply the same
filtering and log levels as usual.

In the process, I also wrote some notes about Rust logging in general on
the Gecko logging page[1].

If there are other env vars like this that would be helpful to target per
process / process type, let's discuss it! There might be a need for
something more general than this one-off addition.

[1]:
https://developer.mozilla.org/docs/Mozilla/Developer_guide/Gecko_Logging#Rust

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

Re: disabled non-e10s tests on trunk

[J. Ryan Stinnett]

I think Ben's argument has merit:

1. Even after Firefox 57, we will still be shipping a product in non-e10s
mode: Firefox for Android
2. If WPT (and potentially other suites) aren't being run in non-e10s mode,
it increases risk because we are shipping untested code paths to our users

Someone might add code that assumes e10s is the only mode and land it
successfully, only later to hear that it fails or crashes on Android, since
e10s doesn't exist there today.

- Ryan

On Tue, Aug 15, 2017 at 3:43 PM, Joel Maher  wrote:

> This is a discussion about tests in e10s mode, not WPT on Android.
>
> What specific coverage are we missing by not running WPT in non-e10s mode
> on desktop?  When can we ensure we have that coverage in e10s mode?  I
> assume this is just making sure the tests that we have disabled on e10s
> mode need to get fixed.
>
> On Tue, Aug 15, 2017 at 4:39 PM, Ben Kelly  wrote:
>
> > On Tue, Aug 15, 2017 at 4:37 PM, Joel Maher  wrote:
> >
> >> All of the above mentioned tests are not run on Android (well
> >> mochitest-media is to some degree).  Is 4 months unreasonable to fix the
> >> related tests that do not run in e10s?  Is there another time frame that
> >> seems more reasonable?
> >>
> >
> > Last I checked it was your team that told me WPT on android was not an
> > immediate priority.  The WPT harness itself does not run there.
> >
> ___
> 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: Removing "MathML View Source" menu item? [was: Can we remove nsIEntityConverter?]

[J. Ryan Stinnett]

As an occasional contributor to view source, I think it would be nice to
remove the MathML support from m-c like you are proposing, as it definitely
increased the maintenance burden when we reworked view source into a tab a
while ago, and my assumption is the usage of MathML view source is
relatively low (though I currently have no data to back that up).

Looking at the add-on, it seems to miss one feature: Currently in m-c, you
can select a portion of a MathML expression, choose "View Selection
Source", and see the MathML source for the selection. If that's added to
your add-on, I believe you'd have feature parity with the existing MathML
view source support.

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1365626 to remove
MathML view source from m-c.

- Ryan

On Sat, May 6, 2017 at 5:40 AM, Frédéric Wang  wrote:

> Le 30/04/2016 à 12:25, Henri Sivonen a écrit :
> > We ship data tables for converting from Unicode to HTML entities.
> > These tables obviously take space. (They are not optimized for space
> > usage, either.) As far as I can tell, these tables are not used at all
> > in Fennec. In desktop Firefox, these data tables are used only for the
> > MathML View Source feature.
> >
> > Additionally, a subset of the tables is used by some XPCOM-based
> > extensions, but those extensions seem to be obsolete or abandoned or
> > don't seem to be using the feature for a very good reason.
> >
> > These data tables are not exposed to the Web Platform.
> >
> > In https://bugzilla.mozilla.org/show_bug.cgi?id=1048191 I proposed
> > removing this for mobile only, but how about we just remove this
> > altogether in order to make both Fennec and desktop Firefox smaller?
> >
>
> Hi,
>
> I'm resurrecting this old thread, just to say that there is now a
> WebExtension implementing the "MathML view source" feature (using better
> syntax highlighting and handling the invisible spaces too):
>
> https://addons.mozilla.org/en-US/firefox/addon/mathml-view-source/
>
> So I'm proposing to remove that feature from the core mozilla source.
> The only concern I have is for Thunderbird/Seamonkey as it is not
> clear yet what will be the future regarding WebExtensions.
>
> Any opinions?
>
> --
> Frédéric Wang
> ___
> 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: Switching to async/await from Task.jsm/yield

[J. Ryan Stinnett]

Sounds like a good change to make from the discussion so far.

If there are issues with stack traces, I would assume having more of our
code base using async / await is a good way to apply pressure for stack
trace improvements (if needed) that will benefit everyone.

- Ryan

On Thu, Mar 16, 2017 at 5:52 PM, Kris Maglione 
wrote:

> On Thu, Mar 16, 2017 at 05:39:06PM -0500, J. Ryan Stinnett wrote:
>
>> For modules that have already converted, is there any performance change
>> (good or bad) between async / await vs. Task?
>>
>
> I haven't noticed any differences either way, but I also haven't done any
> explicit profiling. There's definitely a difference in the way we collect
> async stacks in async/await code vs. with the Promise.jsm promises that
> Task.jsm uses, but that shouldn't show up much on release.
>
>
> On Thu, Mar 16, 2017 at 5:33 PM, Kris Maglione 
>> wrote:
>>
>> On Thu, Mar 16, 2017 at 03:29:15PM -0700, Dave Townsend wrote:
>>>
>>> Writing code in standard JS is always better for the web, makes it easier
>>>> to onboard new engineers and allows for better support in developer
>>>> tools.
>>>> So I'd like to propose that we switch to the standard way of writing
>>>> these
>>>> functions immediately. New code should use async/await instead of
>>>> Task.jsm
>>>> going forwards.
>>>>
>>>>
>>> +1
>>>
>>> I've already started doing this in places where using Task.jsm was
>>> unwieldy, and it's improved things tremendously.
>>>
>>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to async/await from Task.jsm/yield

[J. Ryan Stinnett]

For modules that have already converted, is there any performance change
(good or bad) between async / await vs. Task?

- Ryan

On Thu, Mar 16, 2017 at 5:33 PM, Kris Maglione 
wrote:

> On Thu, Mar 16, 2017 at 03:29:15PM -0700, Dave Townsend wrote:
>
>> Writing code in standard JS is always better for the web, makes it easier
>> to onboard new engineers and allows for better support in developer tools.
>> So I'd like to propose that we switch to the standard way of writing these
>> functions immediately. New code should use async/await instead of Task.jsm
>> going forwards.
>>
>
> +1
>
> I've already started doing this in places where using Task.jsm was
> unwieldy, and it's improved things tremendously.
> ___
> 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: Startup JS debugging (sometimes) possible via Browser Toolbox

[J. Ryan Stinnett]

On Mon, Mar 13, 2017 at 2:04 PM, Jared Wein  wrote:

> Yes, we support watches in the new debugger UI now. The new debugger UI is
> used by default in the Browser Content Toolbox, and it is pretty nice and
> shiny.


New debugger UI is on for Browser Content Toolbox, but at the moment, it's
still off for Browser Toolbox.

It was disabled for Browser Toolbox ~6 months ago in bug 1300820, but those
issues appear to have been resolved since then.

I filed bug 1346902 to enable it again for Browser Toolbox.

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

Re: Startup JS debugging (sometimes) possible via Browser Toolbox

[J. Ryan Stinnett]

On Thu, Mar 9, 2017 at 2:18 AM, Panos Astithas  wrote:

> You almost completely resolved the 4-year-old bug 814298, yay! I now
> wonder if this makes it easier to improve mochitest debugging per bug
> 929535.


Thanks for the pointers to these bugs.

Bug 814298 stills needs breakpoint persistence to be fully resolved, but
this will hopefully appear soon in the new debugger UI.

For mochitest debugging (bug 929535), this new flag does seem to be
sufficient to allow the tests to run automatically while still debugging,
so I've just landed a fix there.

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

Startup JS debugging (sometimes) possible via Browser Toolbox

[J. Ryan Stinnett]

With bug 1275942 in Firefox 55, a new Firefox CLI option was added:
`--wait-for-jsdebugger`.

Example usage:

1. Add "debugger;" to top of browser/base/content/browser.js
2. $ ./mach run --jsdebugger --wait-for-jsdebugger
3. Browser Toolbox opens, pausing Firefox startup at the added line

This triggers Firefox to wait until the debugger connects, which makes it
possible to debug some Firefox startup JS code paths. (Some startup paths
might run before the DevTools command line handler, so for the moment they
won't pause. This could be improved in the future by moving the CLI handler
earlier in startup.)

(If you're wondering why an extra flag was added, this mode makes the
Browser Toolbox use a different default window in the Inspector, which
might confuse people if it was the default.)

Let me know if it's useful and / or you see room for improvement.

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

Re: Deprecating XUL in new UI

[J. Ryan Stinnett]

On Mon, Jan 16, 2017 at 3:08 PM, smaug  wrote:
> On 01/16/2017 10: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.
>
> But XUL has prototype cache which makes for parsing faster and opening new
> windows even faster
> since one needs to just clone from the prototype, and not load anything.
> So, be careful with the performance numbers.

I am not very familiar with the details of XUL prototype cache, but my
understanding of bug 1286082[1] is that currently the XUL prototype
cache is not actually working correctly (and possibly has been broken
since bug 592943[2] landed as part of Firefox 7 in 2011).

So, an even more careful investigation / comparison is warranted. The
prototype cache might not currently be doing anything.

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

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

Re: Deprecating XUL in new UI

[J. Ryan Stinnett]

On Mon, Jan 16, 2017 at 2:43 PM, Dave Townsend  wrote:
> * iframe elements don't have the same capabilities that the XUL browser
> element does and we use that in some UI.

We do have  available to chrome pages on desktop
now (bug 1238160[1], landed in Firefox 47), which should get you a
large part of the way here. It offers features like:

* same chrome / content separation that we have with 
* content loads in separate process, like 
* window.top, etc. work as web content expects them to
* message manager available to load frame scripts, send messages, etc.
* access to docshell, etc. from chrome scripts
* BrowserElement API[2] is available (unclear if desktop actually
wants this API)

It's not really a drop in replacement for  (but I would
guess we don't want it to be anyway, if we hope to reduce XBL usage):

* XBL things like browser.xml aren't used, so many properties from
 aren't present
* browser group frame scripts aren't currently loaded automatically

At the moment, it's only used on desktop by DevTools to implement the
Responsive Design Mode.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1238160
[2]: 
http://searchfox.org/mozilla-central/source/dom/webidl/BrowserElement.webidl

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

Re: Rust required to build Gecko

[J. Ryan Stinnett]

On Wed, Dec 21, 2016 at 12:23 AM, Jim Blandy  wrote:
> I had a .mozconfig file that included the line:
>
> . "$topsrcdir/build/mozconfig.common"

My understanding is that we're generally not supposed to include the
in-tree mozconfigs in our local builds, since they are free to make
various automation-only assumptions, which seems to be what happened
here. It's tempting to do it anyway though, for some abstract feeling
that the build will more closely resemble an official one. (I used to
do something like this as well!)

I believe many people have fallen into this trap over the years, most
likely because of MDN pages[1] that appeared to suggest using
automation mozconfigs directly (there's at least a warning on the page
now).

[1]: 
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Configuring_Build_Options#Example_.mozconfig_Files

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

Re: mach and ccache failure?

[J. Ryan Stinnett]

On Fri, Aug 19, 2016 at 6:16 PM, Andrew McCreight 
wrote:

> I'm not sure of the particulars, but I believe ccache doesn't share the
> results between two object directories unless you set it up explicitly to
> use relative paths. Or something like that.
>
> https://ccache.samba.org/manual.html#_compiling_in_different_directories
>

I used to use the "base_dir" setting that that page recommends to mitigate
this, but it did indeed break C++ debugging for me (like that page warns
you that it might), so I eventually removed it. I'm not aware of a good
path to optimize the multiple object directory case currently.

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

Re: Readable Bug Statuses in Bugzilla

[J. Ryan Stinnett]

On Tue, May 24, 2016 at 11:47 AM, Gijs Kruitbosch
 wrote:
> You can see this in bmo if you have the new/modal/experimental UI enabled (
> https://bugzillatips.wordpress.com/2015/08/07/new-modal-ui-for-show_bug-on-bmo/
> ) .

Kind of a side note, but do we intend to make the "experimental" UI
the site default? If we're adding features that only appear there, we
may want to do that so they make the most impact.

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

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

[J. Ryan Stinnett]

On Thu, May 19, 2016 at 6:24 PM, Xidorn Quan  wrote:
> 2. I cannot retrigger any TC task.
>
> This is pretty annoying when I was debugging intermittent issues. Hopefully
> they could get fix before we migrate all Linux builds to TaskCluster,
> otherwise we will lose the ability to debug certain kinds of bugs with
> Linux builds.

Other people have also mentioned that they can't retrigger these TC
tasks, so this part sounds accurate. Bug 1274176 was filed recently
about this. I hope it will be prioritized, I agree it's frustrating
when working on intermittents.

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

Re: now available on desktop Firefox

[J. Ryan Stinnett]

On Mon, Mar 7, 2016 at 8:00 PM, Jonas Sicking  wrote:
>
> On Mon, Mar 7, 2016 at 1:55 PM, J. Ryan Stinnett  wrote:
> > By default,  can't access the storage used by
> >  for cookies and other site data, making it hard to share page
> > state across the two browser frame types. An additional feature  > mozbrowser noisolation> has been added, which gives the frame access to the
> > same storage as . This is only meant for use on desktop
> > Firefox to allow HTML and XUL browser frames to work together.
>
> Is there a reason we couldn't make 'noisolation' the default behavior
> when  is used by chrome code.
>
> There is currently work going on in Gecko to enable use of multiple
> "cookie jars" in Firefox, this is heavily based on the cookie jar
> implementation that we wrote for FirefoxOS, but it is cleaned up and
> simplified.
>
> I suggest we use that support rather than the old FirefoxOS cookie
> jars. The main reason is that you'll have to deal with painful data
> migration once the new isolation is fully in place.
>
> In practice I expect all data in other cookie jars to be deleted
> rather than migrated at some point in the future.
>
> So what I'm suggesting is:
> * Make  act as if 'noisolation' is set when the
> element is used in chrome documents (documents with a system
> principal).

Yes, that should be fine, at least for desktop. There are some B2G
specific code paths[1] related to apps that will need some additional
work before this could be true on all platforms. I am not sure how
this would be affected by the new B2G approaches mentioned in this
thread.

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1254823 about this.

> * Add support for  similar to
>  which already exist.

This also seems reasonable and should be straightforward to add.

[1]: 
https://dxr.mozilla.org/mozilla-central/rev/05c087337043dd8e71cc27bdb5b9d55fd00aaa26/dom/base/nsFrameLoader.cpp#1640-1647

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

now available on desktop Firefox

[J. Ryan Stinnett]

Do you like HTML? Do you like to build core browsing UI for desktop
Firefox? Now you can have both together!

In more detail,  is now enabled[1] on desktop Firefox.
This makes it possible to create frames for displaying web content (similar
to a ) from HTML chrome pages. This is the same system that
B2G has used for some time to display web content from an HTML UI. (This
feature is not available to web content and is not meant to be used there.)

This gives us a core building block that can be used to build a fully HTML
browser UI. Of course, the existing UI has many XUL / XBL dependencies, but
this is at least one step. The DevTools team plans to use this new feature
quite soon as part of a refreshed Responsive Design Mode. Additionally, it
should make it easier for projects like browser.html to run from unmodified
Firefox.

By default,  can't access the storage used by
 for cookies and other site data, making it hard to share page
state across the two browser frame types. An additional feature  has been added, which gives the frame access to the
same storage as . This is only meant for use on desktop
Firefox to allow HTML and XUL browser frames to work together.

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

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

Re: HTML-based chrome and

[J. Ryan Stinnett]

On Thu, Feb 25, 2016 at 6:32 AM, Benjamin Francis  wrote:
> Thanks for the heads-up. Will this be available to all chrome privileged
> code (i.e. not behind a mozApp permission)? If so, this could be a great
> starting point for what I'm describing. The main differences being the way
> you instantiate a "browser window", and a new chrome-only HTML element with
> a new name and a cleaner API (the current mozBrowser extension to iframes is
> a bit of a mess).

Yes, it's available to any chrome documents. It is gated on the
"browser" permission from mozApps, but the permission manager allows
all permissions for chrome documents by default, so as a result it's
always available in chrome docs. If we removed all the mozApps stuff
at some point, it would just reduce to checking if the document is
chrome for this case.

> Also, is this restricted to desktop or could it be exposed on other
> platforms too (i.e. Android/Gonk)?

The current bug only exposes it on desktop. I would assume it can be
made to work on Android since we had b2gdroid there, and Gonk since
Firefox OS used it. However, I haven't tried these combinations
explicitly as part of the bug I mentioned.

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

Re: HTML-based chrome and

[J. Ryan Stinnett]

We'll soon have access to  in desktop Firefox (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1238160).

I realize you are proposing a different API than mozbrowser, but I
just wanted to point out that there will be some HTML-based approach
for browser chrome available on desktop soon.

- Ryan

On Wed, Feb 24, 2016 at 2:19 PM, Benjamin Francis  wrote:
> Hi,
>
> I've been thinking about working towards deprecating "Open Web Apps" (aka
> mozApps
> )
> in Gecko.
>
> For the most part I think mozApps should eventually be replaced by
> standards-based web apps using Web Manifest, Service Workers etc. I'd love
> to see a standalone display mode for Firefox which supports these web apps
> on desktop and mobile to replace the now defunct web runtime, but that's
> not what this email is about.
>
> For the most privileged pieces of UI like the browser chrome of the
> browser.html project and the Firefox OS system app I think we may need
> another solution. I'd like us to be able to split Gaia
>  into chrome (the system pieces) and
> standard web content (everything else). (I'd also like to see a lot of the
> current mozApps-only DOM APIs become web services).
>
>- In the past we had XULRunner but this has recently been removed and it
>seems the continued use of XUL is being discouraged in favour of HTML.
>- There was an attempt at rebooting the Chromeless project
> but it looks like that was
>still based on XULRunner.
>- The browser.html  project
>currently uses Graphene
>
> ,
>a build of Gecko/Servo which runs locally hosted web content as browser
>chrome, but that's based on certified mozApps and the mozBrowser API.
>
> After chatting with members of the browser.html team I'd like to propose a
> solution inspired by Electron  (which they
> already proposed 
> before ). This would involve a
> new type of HTML-based chrome including a new  element.
>
> Kan-Ru previously did a comparison
>  of Mozilla's
> mozBrowser API, Google's  and Microsoft's  and I started
> to spec something out  with a view
> to potentially standardising this, but the web lacks the security model
> needed to expose this API and there's currently not much interest in a
> standard. So my proposal is a chrome-only  element for Gecko which
> would replace the mozApps-only mozBrowser API
> ,
> along the lines of Electron's  element
> , to allow you to
> safely embed web content in an application with HTML-based chrome.
>
> We could also potentially emulate other parts of Electron's APIs too, see
> their quick start tutorial
>  to get an idea
> of how their embedding works.
>
> Initially this would be used by the browser.html and Firefox OS projects,
> but I think it could be a possible route away from XUL for Firefox in the
> future too.
>
> I've chatted with a few people working on browser.html and Firefox OS about
> this, but I'd like to get broader feedback. Vivien told me he's already
> prototyping a similar solution  to
> the same problem so I'd like to kick off some discussion here about which
> direction we should take.
>
> Thanks
>
> Ben
> ___
> 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: HTML mozbrowser frames on desktop Firefox?

[J. Ryan Stinnett]

I have filed bug 1238160 to investigate and hopefully enable
mozbrowser on desktop Firefox.

- Ryan

On Fri, Jan 8, 2016 at 3:23 PM, J. Ryan Stinnett  wrote:
> On Fri, Jan 8, 2016 at 12:13 PM, Bobby Holley  wrote:
>> Note that enabling a FFOS-oriented API like mozbrowser has the effect of
>> turning it on for web content (with some set of permissions) rather than
>> "for chrome", since that's how things work in FFOS. So any work to use
>> mozbrowser on Desktop should take extreme care not to accidentally expose it
>> to the Web in any way, since the cost of even partially-exposing a
>> non-standard API in Firefox is much higher than in FFOS.
>>
>> I would also imagine that this may not play well with e10s, so you should
>> definitely consult IPC wizards and e10s technical leadership before doing
>> anything in this area.
>
> Okay, that's good to know. I'll reach out to a more focused group to
> have this discussion.
>
> - Ryan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: HTML mozbrowser frames on desktop Firefox?

[J. Ryan Stinnett]

On Fri, Jan 8, 2016 at 12:13 PM, Bobby Holley  wrote:
> Note that enabling a FFOS-oriented API like mozbrowser has the effect of
> turning it on for web content (with some set of permissions) rather than
> "for chrome", since that's how things work in FFOS. So any work to use
> mozbrowser on Desktop should take extreme care not to accidentally expose it
> to the Web in any way, since the cost of even partially-exposing a
> non-standard API in Firefox is much higher than in FFOS.
>
> I would also imagine that this may not play well with e10s, so you should
> definitely consult IPC wizards and e10s technical leadership before doing
> anything in this area.

Okay, that's good to know. I'll reach out to a more focused group to
have this discussion.

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

Re: HTML mozbrowser frames on desktop Firefox?

[J. Ryan Stinnett]

On Fri, Jan 8, 2016 at 4:55 AM, Tim Guan-tin Chien  wrote:
> What prevents you from using ? Is it because the parent
> frame is (X)HTML?

Placing a regular, non-remote  in the HTML page does
work. However,  does not work in my specific
context according to the policy of
nsFrameLoader::TryRemoteBrowser()[1] which requires the  to be inside chrome docshell, such as the root chrome
document. Since I am working from inside a tab, the page is a content
docshell (even though I still have chrome access to Components, etc.),
so these rules block the remote browser for this case.

 is allowed to work in this situation, so
that is one big reason I'd like to use it.

The other reason I want to use  is that I am
using React to manage the content on the page, and creating XUL
elements from within an HTML page is AFAIK not supported by React, so
you have to do some nasty hacking around to make this work.

I'd really prefer to just use HTML elements in my HTML page if I can manage it!

> I don't know what prevents browser-element from being enabled on desktop
> though -- it's tests are running on desktop, and the actual feature is
> hidden behind a permission so we won't expose it to the web content even if
> we turn it on.

Right, I would assume it works fine on desktop from a technical
perspective, since it's used by Mulet and other FxOS simulators that
run on desktop.

[1]: 
https://dxr.mozilla.org/mozilla-central/rev/d4213241bb796fdfa7a5ad4f1989e97b44474364/dom/base/nsFrameLoader.cpp#2250

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

Re: HTML mozbrowser frames on desktop Firefox?

[J. Ryan Stinnett]

(CCing dev-platform as suggested on IRC.)

On Thu, Jan 7, 2016 at 9:58 PM, J. Ryan Stinnett  wrote:
> DevTools is working on rebuilding the responsive design UI in an HTML,
> chrome-scoped page. This page will want to manage child frames to show
> the page content, which could be remote frames. So, I would want to
> use  for cases like these.
>
> However, I noticed mozbrowser frames are currently preffed off
> (dom.mozBrowserFramesEnabled) on desktop. Is there a reason for this?
> Can it be turned on, or is there some kind of work still needed before
> it is usable?
>
> I assume we would eventually want to enable this anyway, so that HTML
> frames can be used in the primary browser UI.
>
> - Ryan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: unowned orange by team

[J. Ryan Stinnett]

On Tue, Dec 22, 2015 at 7:15 PM, Ben Kelly  wrote:
>
> devtools:
> 21) https://bugzilla.mozilla.org/show_bug.cgi?id=992275
> 22) https://bugzilla.mozilla.org/show_bug.cgi?id=1210208
> 23) https://bugzilla.mozilla.org/show_bug.cgi?id=1230031
> 29) https://bugzilla.mozilla.org/show_bug.cgi?id=1209295

For DevTools, I have ni?ed possible assignees for each (and 1 already
has assignee and patch up for review).

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

Re: New heap snapshots tool in the developer tools

[J. Ryan Stinnett]

On Wed, Nov 4, 2015 at 4:51 AM, Wilson Page  wrote:
> I assume we can use it via the WebIDE Devtools?

Yes, indeed you can! I just tried it on Aries to be sure. :)

You will need a recent device build that includes Gecko rev
601528a16cf9 from 2015-10-29. I used the Aries dogfood-latest channel
in my test.

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

Re: mach mozregression command

[J. Ryan Stinnett]

On Wed, Sep 16, 2015 at 1:42 PM, Benoit Girard  wrote:
> I just
> hope that we continue to maintain mozregression as a standalone tool and
> that this wrapper doesn't cause us to miss regressions in it.

The mach wrapper essentially just calls "pip install mozregression"[1]
and passes args along, so the standalone tool should be safe.

[1]: 
https://dxr.mozilla.org/mozilla-central/rev/9ed17db42e3e46f1c712e4dffd62d54e915e0fac/tools/mach_commands.py#398

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

Re: Overview of what you can do with Telemetry

[J. Ryan Stinnett]

On Tue, Aug 11, 2015 at 2:22 AM, Ms2ger  wrote:
> On 08/10/2015 11:25 PM, Vladan Djeric wrote:
>> Intern presentation schedule:
>> https://mana.mozilla.org/wiki/display/globalstaffing/2015+Intern+Presentations
>
> Nothing public?

Here's a public PDF snapshot[1] of the current contents.

Also, the presentations are publicly archived[2] after they are given.

[1]: https://drive.google.com/file/d/0BwVM8svT30XYRC1SeTZaNkRLczQ/view
[2]: https://air.mozilla.org/channels/interns-2015/

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

Re: Intent to implement: Moving DevTools to top level /devtools directory

[J. Ryan Stinnett]

On Thu, Jul 23, 2015 at 8:11 AM, Paul Rouget  wrote:
> I guess by moving things to /devtools/, you also want to update the
> URLs to chrome://devtools/content.
> So then, we can compile and open the devtools with non-firefox builds
> (thunderbird, b2g, seamonkey, ...).
> But if the devtools include browser code, this won't work. For
> example, we import
> chrome://browser/content/utilityOverlay.js, which is Firefox only.

The main goal of this work is around making the DevTools codebase more
approachable for contributors.

We're not explicitly setting out to make reusing the front end easier
from non-Firefox, but certainly moving out of /browser is one nudge in
the right direction down that path.

I'm guessing we'll still have some browser dependencies for the
moment, but I'll take a look at this as I work on the file moves.

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

Intent to implement: Moving DevTools to top level /devtools directory

[J. Ryan Stinnett]

The DevTools team is planning to move our code out of
/browser/devtools and /toolkit/devtools and into a new top level
/devtools directory.

The main goals of this are to reduce confusion for new DevTools
contributors and help us better organize our work in the future. It
will also aid future users of the code in understanding what pieces
they need to include.

There should be no impact to DevTools features shipped in different
products: Firefox desktop will continue to be the only product that
ships the DevTools front end, and all others will ship the DevTools
server only.

It is my understanding that the DevTools team received approval for a
new top level directory from Brendan several years ago.

Bug: https://bugzil.la/912121

(Replies to dev-platform.)

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

Re: "Does jpm support for Thunderbird."

[J. Ryan Stinnett]

The mozilla-labs-jetpack list and/or #jetpack on IRC are probably
better (more focused) places to discuss JPM.

- Ryan

On Thu, Jul 2, 2015 at 5:14 AM, 罗勇刚(Yonggang Luo)  wrote:
> I am looking for it to developing plugins for thunderbird
>
> --
>  此致
> 礼
> 罗勇刚
> Yours
> sincerely,
> Yonggang Luo
> ___
> 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: Rust and Servo training sessions at Whistler

[J. Ryan Stinnett]

On Sched, it appears the Servo session is scheduled for Friday, 1 - 3
PM, is that now the correct date and time?

- Ryan

On Mon, Jun 8, 2015 at 6:20 PM, Lars Bergstrom  wrote:
> Jim,
>
> We won’t get into anything that requires prior Rust experience during the 
> Servo session - the focus is intended to be more on architecture, web 
> platform compat, and with a bit of poking around to make small changes (e.g., 
> either fixing or breaking WPT and CSS WG ref tests with tiny code changes).
>
> Ideally, we would have had the Rust one first, but the Thursday slot had 
> fewer conflicts and there were more groups interested in the Rust training 
> than the Servo one.
> - Lars
>
> On Jun 8, 2015, at 5:15 PM, Jim Chen  wrote:
>
> Does the Servo session (which is earlier than the Rust session) require prior 
> experience with Rust?
>
> Thanks,
> Jim
>
>
> On 6/8/15 3:44 PM, Lars Bergstrom wrote:
>> The Research team will be holding a pair of 3 hour training sessions, with 
>> one on the new web rendering engine, Servo, and one on the new systems 
>> language it is implemented in, Rust. These sessions will have both 
>> presentation components and a large hands-on piece with exercises to do on 
>> your laptops. The Rust session will also have some content on building Rust 
>> code into Gecko.
>>
>> If you are interested in attending, please sign up on the Sched links below 
>> (you will have to log in and then click the “Add To My Sched” button). The 
>> numbers will help us figure out how many USB sticks to bring, how many 
>> people we need to have staffing the training, whether there is enough space 
>> in the booked room, whether we have enough stickers, etc.
>>
>> The Platform admins and managers have helped ensure that the Rust session 
>> will not conflict with any team’s meetings and that the Servo one will not 
>> conflict with meetings for teams that work on browser features, so you 
>> shouldn’t need to worry about something getting booked over them.
>>
>> Servo - Wednesday, 1–4 PM: http://sched.co/3ZQn 
>> Rust - Thursday, 1–4 PM: http://sched.co/3ZQp 
>>
>> Please don’t hesitate to reach out if there are specific things you’d like 
>> to see us cover, as we’re making up the training materials right now.
>>
>> Thanks!
>> - Lars
>> ___
>> 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: IndexedDB transactions are no longer durable by default, and other changes

[J. Ryan Stinnett]

On Wed, Apr 8, 2015 at 2:30 PM, Botond Ballo  wrote:
> Have we considered issuing a warning saying that after upgrading the
> profile, it will not be compatible with older versions?

I would really like to have something like this. WebIDE makes use of
IndexedDB today, and it seems to trigger uncatchable errors in some
cases when an older client is used with newer profile (see WebIDE bug
1117129), so it's hard to handle at the application level today.

Some people (at least at Mozilla) move their profiles between up and
down versions regularly, so we should at least look for a way to offer
a nice warning.

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

Re: DevTools and Intent to Implement process

[J. Ryan Stinnett]

On Tue, Mar 31, 2015 at 3:07 PM, J. Ryan Stinnett  wrote:
> The DevTools team has recently discussed[1] this, and we thought
> becoming more integrated in the platform "Intent to Implement" process
> would be a good thing to do.  Specifically, we'd like to have a
> "DevTools" line in the "intent to implement" template[2] which would
> link to a bug on building tools for the feature for further
> discussion.

Since I received 1 reply in favor and 0 opposed, I've gone ahead and
added a line to the "Intent to Implement" template for this purpose.

I hope this will lead to earlier discussion between our teams, which
should be beneficial to all involved. If it ends up not working out,
we can always revisit the idea.

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

Re: DevTools and Intent to Implement process

[J. Ryan Stinnett]

On Tue, Mar 31, 2015 at 3:47 PM, Jet Villegas  wrote:
> We've started implementing the Web Animations API [1] with very early
> collaboration with the Dev Tools team and have seen very promising results.
> Is that a model we can continue to follow or modify to suit?

While I was not directly involved in this work, I believe that model
worked well overall from what I could tell.

Getting involved early does mean things may be less stable or subject
to change as Patrick mentions[1], but the benefits of early feedback
for both platform and DevTools teams are still much more valuable
overall. I am sure we can smooth out this process in the future, as
I've only seen it happen a few times so far.

So yes, I think it's a good model to work from. Let's do more of it!

[1]: 
https://groups.google.com/d/msg/mozilla.dev.developer-tools/fZOxb3t0Npk/_LXhVKSgs6EJ

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

DevTools and Intent to Implement process

[J. Ryan Stinnett]

DevTools would like to get involved earlier in the implementation
process for new platform features.

In particular, we'd like to head towards a world where:

1. Platform features are architected in such a way from the start that
adding debugging / instrumentation is (relatively) easy
2. DevTools for a feature are discussed early on in a bug that
interested parties can follow while the platform feature is being
implemented

By working with the platform team as features are developed (instead
of afterwards), we can discuss any debugging and instrumentation APIs
our tools may need, give feedback as we start to build tools, etc.
We're hoping this will help us to release tools closer to the time
frame that the platform features are available.  Tools for new
features should increase adoption of those features, as they make it
easier for web developers to explore and understand them.

The DevTools team has recently discussed[1] this, and we thought
becoming more integrated in the platform "Intent to Implement" process
would be a good thing to do.  Specifically, we'd like to have a
"DevTools" line in the "intent to implement" template[2] which would
link to a bug on building tools for the feature for further
discussion.

Thoughts? (Replies to dev-platform.)

[1]: 
https://groups.google.com/forum/#!topic/mozilla.dev.developer-tools/fZOxb3t0Npk/discussion
[2]: https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement

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

Re: Is anyone still using JS strict warnings?

[J. Ryan Stinnett]

Some prior discussion of this feature happened in the platform thread
"Disabling
strict warnings as errors in xpcshell"[1].

A few people argued for the extra warnings to be removed, while one person
said they were useful.

No clear conclusion was reached.

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

On Fri, Dec 19, 2014 at 2:19 PM, Jason Orendorff 
wrote:
>
> So if you go to about:config and set the javascript.options.strict pref,
> you'll get warnings about accessing undefined properties.
>
> js> Math.TAU
> undefined
> /!\ ReferenceError: reference to undefined property Math.TAU
>
> (It says "ReferenceError", but your code still runs normally; it really is
> just a warning.)
>
> Is anyone using this? Bug 1113380 points out that the rules about what kind
> of code can cause a warning are a little weird (on purpose, I think). Maybe
> it's time to retire this feature.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1113380
>
> Please speak up now, if you're still using it!
>
> -j
> ___
> 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: prebuilt libraries?

[J. Ryan Stinnett]

On Wed, Nov 26, 2014 at 10:48 AM, Gregory Szorc  wrote:

> The high-level cache requires separate things. Modern build systems have
> artifact caches built in. They can jump straight to the end result and skip
> intermediaries. We can't have nice things with the 30+ year old tool that
> is GNU Make. Well, we could, it just require us to invent a build mode that
> short-circuits compilation, linking, etc and manually fetches the final
> object from the cache. IMO we should build this for Firefox and Firefox OS
> developers. We kinda/sorta already have this in xulrunner and parts of
> Firefox OS builds. We know the approach works. We just need to make it
> turnkey and better integrated with release automation.
>

Are there any bugs on file with more details about the work needed to get
this kind of high level cache for Firefox and/or Firefox OS?

As you say, this would dramatically improve build times for front end
changes that don't involve C++ at all.

If this is too OT for the thread, please ping me on IRC. I'd like to help
drag this forward if I can.

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

Re: e10s is now enabled by default for Nightly!

[J. Ryan Stinnett]

On Fri, Nov 7, 2014 at 4:39 PM, Gijs Kruitbosch
 wrote:
> Are we currently planning to let this default ride into aurora in 2 weeks'
> time?

>From Chris's first message: "e10s will not ride the trains to Aurora 36."

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

Re: Windows 10 package manager

[J. Ryan Stinnett]

On Wed, Oct 29, 2014 at 1:25 AM, Justin Dolske  wrote:
> http://www.extremetech.com/computing/192950-windows-10-will-come-with-a-command-line-package-manager-much-to-the-lament-of-linux-users
>
> "With Windows 10, however, we are finally getting an official package
> manager: OneGet. In the current build of Windows 10 Technical Preview, you
> can open up PowerShell and use OneGet to install thousands of applications
> with commands such as Find-Package VLC and Install-Package Firefox."
>
> Anyone know how the OneGet works? Are they actually repackaging and
> redistributing Firefox in some new format (which would be, uhm, surprising)?

Appears[1] to be a "package manager manager" that can wrap multiple
package sources with one interface.

Wrapping Chocolatey[2] is mentioned most, so probably it uses their scripts.

The Firefox package[3] seems to just download our usual EXE.

[1]: https://github.com/OneGet/oneget
[2]: https://chocolatey.org/
[3]: https://chocolatey.org/packages/Firefox
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: fine-grained filtering of bugmail

[J. Ryan Stinnett]

On Fri, Aug 22, 2014 at 9:40 AM, Kyle Huey  wrote:
> How do I filter out all changes to the qe-verify flag?

Bug 1054138 is needed before that's possible.

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

Re: How to implement XPCOM API void render(in long width, in long height, out nsIImageLoadingContent imageContent); in Javascript?

[J. Ryan Stinnett]

On Fri, Aug 22, 2014 at 7:54 AM, Boris Zbarsky  wrote:
> On 8/22/14, 5:34 AM, David Rajchenbach-Teller wrote:
>>
>> If I recall correctly, this is implemented as an object with a field
>> `out` – I'm not 100% sure of the name of the field, though, so you might
>> need to experiment.
>
>
> The field name is "value".
>
> I should note that searching the web for "xpcom out parameter" comes up with
> the answer to the original question in this thread as the first hit in
> Google, Bing, and Yahoo, and within the top 5 on DuckDuckGo, as far as I can
> tell  It would be nice if people took the two minutes to do a search
> like that before asking on this list.  ;)

Also, ask.m.o[1] might be a better place to ask many of the "how do I
do...?" questions that Yonggang has been posting. But yes, search
first. :)

[1]: https://ask.mozilla.org

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

Re: Google announces Chrome builds for Win64

[J. Ryan Stinnett]

On Thu, Jun 5, 2014 at 10:03 AM, Robert Kaiser  wrote:
>> It's also security boost for 64 bit users.
>
>
> Could someone please explain why you and Google claim 64bit to be more
> secure? This is a new argument to me and I wonder what's behind it.

As stated in Google's announcement[1], the main security improvement
is (better) address space layout randomization. Even though that
exists in 32 bit too, it's more effective with 64 bit since the VM
space is so much larger. Looks like Windows has a specific "high
entropy"[2] version that's 64 bit only.

[1]: http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-canary-and.html
[2]: 
http://blogs.technet.com/b/srd/archive/2013/12/11/software-defense-mitigating-common-exploitation-techniques.aspx

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