Re: PSA: nsIURI implementations are now threadsafe

Do we have any plan to be able to use NS_NewURI() off-main-thread? I thought that was included here, but I see now that it is not. The initial URL parse OMT is important for truly being able to remove all our "bounce to the main thread for URL stuff" legacy code. On Fri, Mar 23, 2018 at 8:25 AM,

Re: The future of "remote XUL"

On 3/27/18 11:50 AM, Nicholas Alexander wrote: - some of the details of "likely to break remote XUL consumers"?  Which consumers are these -- internal?  External? This is referring to my proposed XPConnect/Components changes, right? External. We have no internal consumers of remote XUL outsid

Re: Style proposal: char32_t for Unicode scalar values

On 3/26/18 1:48 AM, Henri Sivonen wrote: Rationale: Say what you mean when the language has vocabulary to do so. Amen. I'd be happy with char32_t for scalar values. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mo

Re: The future of "remote XUL"

On 3/27/18 1:02 PM, Eric Shepherd wrote: ​Yes, that's true. My thinking is that a first step could be to change it so it had to be enabled using Policy Engine, and have an ESR release with that So presumably targeting 60? The timing is a bit tight... Note that as things stand the only way to

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

On 3/26/18 6:29 PM, Myk Melez wrote: Do any of those bits of C++ code depend on a particular feature of XPCOM They depend on the dynamic casting provided by QueryInterface. That said, they could in many cases switch to other methods of dynamic casting that are more limited... or do they jus

The future of "remote XUL"

(I tried to send this to dev-platform@lists.mozilla.org, but tha's not coming through for some reason There is parallel discussion in firefox-dev if people want to try to track both.) Background: We currently have various provisions for "remote XUL", wherein a hostname is whitelisted to:

The future of "remote XUL"

Background: We currently have various provisions for "remote XUL", wherein a hostname is whitelisted to: 1) Allow parsing XUL coming from that hostname (not normally alllowed for the web). 2) Allow access to XPConnect-wrapped objects, assuming someone hands out such an object. 3) Run XB

Re: The future of "remote XUL"

On 3/27/18 12:56 PM, Brian Grinstead wrote: Wouldn't keeping it for file:// require us to maintain the infrastructure, or is there something that makes it worse in the whitelisted domain case? It's a question of what guarantees we offer for XUL working. Keeping it for file:// requires keeping

Re: The future of "remote XUL"

On 3/27/18 11:50 AM, Eric Shepherd (Sheppy) wrote: The one potential exception: would it make sense to allow it to be enabled (with it disabled by default) on copies of Firefox set up with Policy Engine, to allow those users the option? That would require maintaining the remote XUL infrastruct

Re: PSA: nsIURI implementations are now threadsafe

On 3/23/18 8:25 AM, Valentin Gosu wrote: I would like to announce that with the landing of bug 1447194, all nsIURI implementations in Gecko are now threadsafe, as well as immutable. Valentin, Thank you very much for doing this! Just the safety guarantees from URI immutability are a huge deal

Re: The future of "remote XUL"

On 3/27/18 12:39 PM, Alex Gaynor wrote: Do we have any telemetry on whether people actually use it? I don't believe we do. Are there any reasons to want to keep it around, besides backwards compatibility? Ease of writing tests and debugging XUL stuff (hence the thought to maybe keep it fo

Re: The future of "remote XUL"

On 3/27/18 11:49 AM, Alex Gaynor wrote: What was the original intended use case for remote XUL, powerful origins controlled by Mozilla, or enabling developers to build their own powerful origins? The latter. In particular, it was used for intranet apps. Note that the remote XUL origins are n

Re: Intent to unprefix: ::-moz-selection.

On 3/26/18 4:13 PM, Boris Zbarsky wrote: On 3/26/18 3:16 AM, Emilio Cobos Álvarez wrote: However other engines have shipped this unprefixed for a long time with the same semantics that we implement https://bugzilla.mozilla.org/show_bug.cgi?id=509958#c14 claims the semantics are not actually q

Re: Intent to unship: CSSStyleDeclaration.getPropertyCSSValue

On Fri, Mar 23, 2018 at 9:16 PM, L. David Baron wrote: > I should clarify that it isn't actually non-standard: it was part > of DOM Level 2: > https://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSStyleDeclaration > but ended up never being widely implemented. It's not a > particularly nice AP

Re: PSA: nsIURI implementations are now threadsafe

This is so great. Thank you! One question that comes to mind, though, is there any chance this could be uplifted to 60? As we start doing more OMT nsIURI stuff its going to become difficult to uplift code to 60ESR. On Fri, Mar 23, 2018 at 8:25 AM, Valentin Gosu wrote: > Hello everyone, > > I

Re: The future of "remote XUL"

My understanding is that it has been effectively unsupported for some time anyway so I think we should just go ahead and disable it altogether at this point. If we need bits for automated tests then we should work to switch tests away from those if we can. On Tue, Mar 27, 2018 at 8:36 AM Boris Zba

Re: PSA: nsIURI implementations are now threadsafe

Yes, that is definitely something we want to fix, but not very straightforward. We have quite a few URI implementations, and a bunch more protocol handlers. https://github.com/valenting/gecko/wiki/Threadsafe-URIs-progress#protocol-handler-implementations On 26 March 2018 at 15:24, Ben Kelly wro

Browser Architecture Newsletter 6 (S02E01)

FADE IN DINGY OFFICE INTERIOR Camera zooms out to reveal BROWSER ARCHITECTURE ENGINEER, typing furiously. It’s S02E01 of Browser Architecture Newsletters! Desktop Technology Stack The Browser Architecture group is working hard to tackle some large problems with the technology stack used to bu

Intent to unship: nsIEditor.numberOfUntoItems and nsIEditor.numberOfRedoItems

A patch to remove nsIEditor.numberOfUntoItems and nsIEditor.numberOfRedoItems are now landed: https://bugzilla.mozilla.org/show_bug.cgi?id=1448780 As far as I've investigated, nobody (including comm-central and bluegriffon) uses these XPCOM methods since those methods exactly equal to nsIEdito

Re: PSA: nsIURI implementations are now threadsafe

On Mon, Mar 26, 2018 at 10:47 AM, Valentin Gosu wrote: > Yes, that is definitely something we want to fix, but not very > straightforward. We have quite a few URI implementations, and a bunch more > protocol handlers. > > https://github.com/valenting/gecko/wiki/Threadsafe-URIs- > progress#protoco

Re: The future of "remote XUL"

Hi Boris! On Tue, Mar 27, 2018 at 8:36 AM, Boris Zbarsky wrote: > Background: We currently have various provisions for "remote XUL", wherein > a hostname is whitelisted to: > > 1) Allow parsing XUL coming from that hostname (not normally alllowed for > the web). > > 2) Allow access to XPConnec

Re: PSA: nsIURI implementations are now threadsafe

On 26 March 2018 at 16:53, Ben Kelly wrote: > On Mon, Mar 26, 2018 at 10:47 AM, Valentin Gosu > wrote: > >> Yes, that is definitely something we want to fix, but not very >> straightforward. We have quite a few URI implementations, and a bunch more >> protocol handlers. >> >> https://github.com/

Re: The future of "remote XUL"

I would agree that going all-out and disabling remote XUL entirely makes the most sense, except in the cases you mention. The one potential exception: would it make sense to allow it to be enabled (with it disabled by default) on copies of Firefox set up with Policy Engine, to allow those users th

Re: The future of "remote XUL"

On Tue, Mar 27, 2018 at 03:48:24PM +, Dave Townsend wrote: My understanding is that it has been effectively unsupported for some time anyway so I think we should just go ahead and disable it altogether at this point. If we need bits for automated tests then we should work to switch tests away

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

Bobby Holley 2018 March 12 at 12:25 That's not how I'd define XPCOM - XPCOM existed before XPIDL/XPConnect (and the name XPConnect means "connecting Javascript to XPCOM"). But quibbling over the definition isn't really useful. I was aware that XPCOM predated XPConn

Re: Components and QueryInterface can no longer be used in non-system globals

Ironically, the timing is impressive here. I just this morning noticed that the tables of inheritance we have in JSON for APIs includes LegacyQueryInterface among the mixins implemented by a number of interfaces, and was already in the process of creating a PR to remove that since it should never h

Re: Can we focus more on color management support?

On Friday, March 23, 2018 at 3:56:05 PM UTC+1, justfor...@gmail.com wrote: > Chrome, Safari treat untagged images as sRGB, can read tagged ICCv4 images > and support video color management. > > Firefox does not have these features by default. Any ETA? Note that (partial?) support for ICCv4 profi

Unaligned NEON memory access on ARMv7 phones

I'm having trouble finding reliable information about the performance of unaligned NEON memory access on ARMv7 phones. What I can find is: * ARMv7 seems to allow unaligned access to be a trap-to-kernel kind of performance disaster, but it's hard to find information about whether the phone SoCs w

Re: How much do we care about pre-Nehalem performance?

On Tue, Mar 27, 2018 at 1:36 PM, Henri Sivonen wrote: > Do I read agner.org correctly that movdqa was obsoleted by Nehalem, > Silvermont and Bulldozer in the sense that movdqu is no worse than > movdqa on those or later microarchitectures? http://www.agner.org/optimize/instruction_tables.pdf for

Re: The future of "remote XUL"

What was the original intended use case for remote XUL, powerful origins controlled by Mozilla, or enabling developers to build their own powerful origins? Alex On Tue, Mar 27, 2018 at 11:36 AM, Boris Zbarsky wrote: > Background: We currently have various provisions for "remote XUL", wherein >

Intent to unship: nsIClipboardDragDropHooks and nsIClipboardDragDropHookList interfaces

I'd like to remove nsIClipboardDragDropHooks and nsIClipboardDragDropHookList interfaces: https://bugzilla.mozilla.org/show_bug.cgi?id=1448876 These interfaces provide ability to override drag and drop operation and paste operation on editor. However, currently, this feature isn't used by anyb

How much do we care about pre-Nehalem performance?

Do I read agner.org correctly that movdqa was obsoleted by Nehalem, Silvermont and Bulldozer in the sense that movdqu is no worse than movdqa on those or later microarchitectures? Do we have numbers of how our installed base is split between earlier than Nehalem/Silvermont/Bulldozer vs. Nehalem/Si

CPU core count game!

Just to drive home a point, let's play a game. First, guesstimate what percentage of our users have systems with 2 or fewer cores. Then visit https://hardware.metrics.mozilla.com/#goto-cpu-and-memory to check your guess. (I didn't say it was a *fun* game.)