Re: NS_NewURI is now thread-safe

[Cameron McCormack]

This is going to let us simplify a whole lot of URL handling code in the style 
system, where we otherwise have to store strings and lazily creating nsIURIs 
when we're back on the main thread.  Thanks so much!

On Mon, Jun 10, 2019, at 1:08 PM, Valentin Gosu wrote:
> Hello everyone,
> 
> nsIURI has been immutable for a few releases now, meaning once you had one
> it was safe to use it on any thread (even change it using nsIURIMutator).
> But until recently you couldn't create a new URI off the main thread
> (unless you already knew the type of the URI).
> A few days ago I closed bug 922464
> , which means nsIURI
> can now be safely used and created on any thread via NS_NewURI. It also
> means nsIProtocolHandler.newURI no longer exists, and if you want to add
> any other special scheme to Gecko you should do so in NS_NewURI in
> nsNetUtil.cpp
> 
> Most of the work happened in bug 1536744
> . This unblocks work
> to make make nsIPrincipal thread safe in bug 1443925
> .
> I've noticed there are some places that keep URIs around as strings. If
> those strings are regularly used to create nsIURIs, I strongly encourage
> you to do so from the beginning.
> 
> There is still work to be done in order to reduce the number of
> implementations we have for nsIURI and resolve our incompatibilities with
> the URL spec. Stay tuned.
> 
> Let me know if you uncover any issues, or if you have any questions.
> 
> Cheers!
> -- 
> Valentin
> ___
> 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: NS_NewURI is now thread-safe

[Bobby Holley]

This is awesome work and has been years in the making. Thanks to everyone
involved for getting it over the line!

On Mon, Jun 10, 2019 at 1:42 PM Valentin Gosu 
wrote:

> On Mon, 10 Jun 2019 at 22:25, Boris Zbarsky  wrote:
>
> > On 6/10/19 4:07 PM, Valentin Gosu wrote:
> > > which means nsIURI
> > > can now be safely used and created on any thread via NS_NewURI.
> >
> > That's awesome news!
> >
> > > and if you want to add any other special scheme to Gecko you should do
> > so in NS_NewURI in
> > > nsNetUtil.cpp
> >
> > Here "special" is in the sense of "Parsed as anything other than a basic
> > nsSimpleURI"?
> >
>
> That's absolutely correct.
>
> nsSimpleURI is the default parser for unknown schemes, and at the moment it
> has the downside of not having a hostname. So if need URIs of a certain
> scheme to have a hostname, you probably need to add code to create the
> correct type - probably an nsStandardURL.
> ___
> 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: NS_NewURI is now thread-safe

[Valentin Gosu]

On Mon, 10 Jun 2019 at 22:25, Boris Zbarsky  wrote:

> On 6/10/19 4:07 PM, Valentin Gosu wrote:
> > which means nsIURI
> > can now be safely used and created on any thread via NS_NewURI.
>
> That's awesome news!
>
> > and if you want to add any other special scheme to Gecko you should do
> so in NS_NewURI in
> > nsNetUtil.cpp
>
> Here "special" is in the sense of "Parsed as anything other than a basic
> nsSimpleURI"?
>

That's absolutely correct.

nsSimpleURI is the default parser for unknown schemes, and at the moment it
has the downside of not having a hostname. So if need URIs of a certain
scheme to have a hostname, you probably need to add code to create the
correct type - probably an nsStandardURL.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: NS_NewURI is now thread-safe

[Boris Zbarsky]

On 6/10/19 4:07 PM, Valentin Gosu wrote:

which means nsIURI
can now be safely used and created on any thread via NS_NewURI.


That's awesome news!


and if you want to add any other special scheme to Gecko you should do so in 
NS_NewURI in
nsNetUtil.cpp


Here "special" is in the sense of "Parsed as anything other than a basic 
nsSimpleURI"?


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

NS_NewURI is now thread-safe

[Valentin Gosu]

Hello everyone,

nsIURI has been immutable for a few releases now, meaning once you had one
it was safe to use it on any thread (even change it using nsIURIMutator).
But until recently you couldn't create a new URI off the main thread
(unless you already knew the type of the URI).
A few days ago I closed bug 922464
, which means nsIURI
can now be safely used and created on any thread via NS_NewURI. It also
means nsIProtocolHandler.newURI no longer exists, and if you want to add
any other special scheme to Gecko you should do so in NS_NewURI in
nsNetUtil.cpp

Most of the work happened in bug 1536744
. This unblocks work
to make make nsIPrincipal thread safe in bug 1443925
.
I've noticed there are some places that keep URIs around as strings. If
those strings are regularly used to create nsIURIs, I strongly encourage
you to do so from the beginning.

There is still work to be done in order to reduce the number of
implementations we have for nsIURI and resolve our incompatibilities with
the URL spec. Stay tuned.

Let me know if you uncover any issues, or if you have any questions.

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

Image format documentation review requested

[Eric Shepherd (Sheppy)]

I’ve just finished writing up a guide to image file types and formats.
Before making it widely hooked into the main body of our documentation, I
would like to get it reviewed by engineers to ensure accuracy.

https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types

Feel free to edit the article in place (log in to MDN and click the edit
button at the top of the page), or if you’re uncomfortable with that, just
email me your suggestions.

Things to look for:


   - Factual errors
   - Things that are important that aren’t mentioned
   - Things mentioned that should not be
   - Anything explained awkwardly
   - Anything else you think should be fixed, changed, or added

The goal isn’t to be a complete detailed list of every fact about every
format, but to provide enough information to allow a developer to decide
what makes sense for them to use.


Eric Shepherd
Senior Technical Writer
MDN Web Docs 
Blog: https://www.bitstampede.com/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: To what extent is sccache's distributed compilation usable?

[Jonathan Watt]

Just in case you're not aware of it, there are a couple of perf issues that may
make people prefer ccache for now:

https://github.com/mozilla/sccache/issues/219
https://github.com/mozilla/sccache/issues/160

Jonathan

On 07/06/2019 18:13, Chris M. wrote:
> I've been working through issues with distributed sccache, but I've
> recently sent instructions to people currently running icecream in the SF
> office on how to switch to running sccache-dist with IT managed hardware.
> We're going to use that as a test bed before rolling out more widely, and
> if all goes well there this should happen shortly (likely shortly after
> returning from Whistler).
> 
> Regarding that bug, that's tracking IT work for the most part so probably
> needs to stay restricted. Most of the work I've been doing is tracked in
> sccache's github repo and can be followed there, or tracked by
> https://bugzilla.mozilla.org/show_bug.cgi?id=1499145.
> 
> Chris
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Bogdan Maris]

Hello,

Here's the list of new issues found and filed by the Desktop Release QA team 
last two weeks.
Additional details on the team's priorities last week, as well as the plans for 
the current week are available at: https://tinyurl.com/yxf24ctb
Bugs logged by Desktop Release QA in the last 7 days

Firefox: Address Bar
NEW - https://bugzil.la/1557302 - Extra space is not being generated if the 
user manually inputs the full @ search engine name (ex @google) and presses the 
enter key inside the URL bar

Firefox: Activity Streams: New Tab
NEW - https://bugzil.la/1557304 - “About:welcome” cards overlapping issue with 
the browser resized to minimum width

Firefox: File Handling
NEW - https://bugzil.la/1557731 - After updating Firefox does not remain pinned 
to the taskbar after restarting
NEW - https://bugzil.la/1557747 - Cannot drag and drop Firefox from the start 
menu to the taskbar

Firefox: Installer
NEW - https://bugzil.la/1557751 - Pin to taskbar gets stuck after toggling the 
option several times

Core: Security: PSM
NEW - https://bugzil.la/1556472 - Importing passwords from Chrome on Windows 
fails on a new profile with -migration

Core: Panning and Zooming
NEW - https://bugzil.la/1556777 - While in presentation mode the background 
webpage and browser UI can be zoomed in and out

Toolkit: Reader Mode
ASSIGNED - https://bugzil.la/1557256 - accel + Mouse scroll still uses full 
page zoom (instead of font size changes) in Reader mode

Toolkit: XUL Widgets
NEW - https://bugzil.la/1557285 - The tree-input textbox from the One-Click 
Search Engines panel overlaps the vertical scrollbar

DevTools: Responsive Design Mode
NEW - https://bugzil.la/1557688 - RDM expanding past viewport and reverting to 
a smaller scale does not follow mouse properly

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

Regards,
Bogdan (:bogdan_maris)
Desktop Release QA

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

Re: Running C++ early in shutdown without an observer

[David Teller]

On 10/06/2019 10:28, Henri Sivonen wrote:
>>> Observers are automatically cleaned up at XPCOM shutdown, so you
>>> generally don't need to worry too much about them. That said,
>>> nsIAsyncShutdown is really the way to go when possible. But it currently
>>> requires an unfortunate amount of boilerplate.
> 
> Thanks. (nsIAsyncShutdown indeed looks like it involves a lot of boilerplate.)

I'll be happy to review patches that scrap the boilerplate :)

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

Re: Running C++ early in shutdown without an observer

[Henri Sivonen]

On Fri, Jun 7, 2019 at 9:45 PM Chris Peterson  wrote:
>
> On 6/7/2019 9:36 AM, Kris Maglione wrote:
> > On Fri, Jun 07, 2019 at 09:18:38AM +0300, Henri Sivonen wrote:
> >> For late shutdown cleanup, we have nsLayoutStatics::Shutdown(). Do we
> >> have a similar method for running things as soon as we've decided that
> >> the application is going to shut down?
> >>
> >> (I know there are observer topics, but I'm trying to avoid having to
> >> create an observer object and to make sure that _it_ gets cleaned up
> >> properly.)
> >
> > Observers are automatically cleaned up at XPCOM shutdown, so you
> > generally don't need to worry too much about them. That said,
> > nsIAsyncShutdown is really the way to go when possible. But it currently
> > requires an unfortunate amount of boilerplate.

Thanks. (nsIAsyncShutdown indeed looks like it involves a lot of boilerplate.)

> Note that on Android, you may never get an opportunity for a clean
> shutdown because the OS can kill your app at any time.

My use case relates to Windows only.

-- 
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform