Re: Intent to remove: Ability to specify the Raanana macOS system font by its Hebrew name in CSS

[Jet Villegas]

* Including a special-case check for the name Raanana when enumerating
> the system fonts
>


My preference as well, though I'm not convinced it's worth doing.

The Wikipedia page for the city of Ra'anana [0] marks up the city's Hebrew
name as:

רַעֲנָנָה‎

The Hebrew version [1] doesn't specify Hebrew fonts at all.

I often use Wikipedia as my unusual font reference site, though it's
certainly not exhaustive. Then again, if there's one place to use the
רַעֲנָנָה font, it would be in רַעֲנָנָה :-)

[0] https://en.wikipedia.org/wiki/Ra'anana
[1] https://he.wikipedia.org/wiki/%D7%A8%D7%A2%D7%A0%D7%A0%D7%94
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: Ability to specify the Raanana macOS system font by its Hebrew name in CSS

[Henri Sivonen]

I'm in the process of rewriting our encoding converter infrastructure
in Rust. For a new implementation, it makes sense to support only the
Web-exposed encodings, that is, the encodings specified in the
Encoding Standard.

Currently, Firefox supports decoding non-Encoding Standard encodings
in one place: in TrueType system font names. TrueType fonts can
declare multiple names and the encoding of the names is specified on a
per-name basis.

Based on telemetry, Gecko sees these very rarely except for MacHebrew
on Mac, which is due to the set of system-bundled fonts containing a
font, Raanana, that declares one of its names in MacHebrew, and
Firefox enumerates all system fonts. This is not telemetry of the font
getting used but the decoder getting instantiated.

It also happens that Raanana doesn't declare its Hebrew name in
another way (Unicode or windows-1255), so removing support for
non-Encoding Standard font names has the effect of removing the
ability to specify Raanana by its Hebrew name in CSS. (I'm not
actually sure if Raanana is the only macOS-bundled font like this.)

https://hsivonen.com/test/moz/raanana.html indicates that Safari
supports specifying Raanana by its Hebrew name but Chrome doesn't.
That is, by making this change we'd end up with Chrome parity but
would break Safari parity. Sites that have been tested in Chrome can
already be expected to refer to Raanana at least by its Romanized
name.


Answers to anticipated questions:


Won’t this make our TrueType support incomplete?

We already don’t support all possible legacy TrueType font name
encodings, and the names only matter for fonts installed on the
system, so as long as present-day OS-bundled fonts work (well enough)
we don't need to support everything that ever existed.


How rare are the cases other than MacHebrew-on-Mac?

Except for MacHebrew-on-Mac, each of the non-Roman, non-Cyrillic
single-byte Mac encoding is seen in 0.00% of Firefox sessions. Even in
the cases where this isn't absolutely zero (i.e. it's only zero to two
decimal places), there are further mitigating factors: 1) The fonts
may be declaring their name(s) also in Unicode or in a supported
Windows legacy encoding. 2) Fonts that are this rare don't make sense
to specify on Web sites except for fingerprinting purposes. (That is,
when Web authors specify fonts that reside on the user's system as
opposed to being downloaded from the Web, they tend to want to specify
widely-available system-bundled fonts.)


Are Web Fonts affected?

No. The @font-face mechanism points to fonts by URL and ignores the
names declared within the font files.


Can Raanana still be used?

Yes, by using the Romanized name "Raanana".


Are there alternatives to removing support for the Hebrew name of Raanana?

Yes, but they are more complex than just removing support. This is the
opportunity for interested parties to advocate for the alternatives,
though. The alternatives are:

* Including a MacHebrew decoder in Gecko outside the normal converter
infrastructure only for the purpose of decoding system font names.

* Decoding MacHebrew font names on macOS only by calling the system
converter API for MacHebrew only.

* Including a special-case check for the name Raanana when enumerating
the system fonts and adding a synthetic entry for the Hebrew name in
Gecko's data structures when the Romanized name is seen (and doing the
same for other macOS-bundled Hebrew fonts that have a Hebrew name in
MacHebrew only if other such fonts exist). (This is my preference for
an alternative to outright removal of the ability to specify Raanana
by its Hebrew name.)

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

Re: Intent to implement and ship: URLSearchParams from array or object

[smaug]

So we'll get support for object too in FF53, not only array?

On 01/17/2017 07:11 PM, Andrea Marchesini wrote:

Summary: URLSearchParams constructor is changed in the latest URL spec.
Now it's possible to create URLSearchParams objects starting from a string,
an array and from an object.

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

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



bug 1321623 has nothing to do with this ;)


Link to standard:
https://url.spec.whatwg.org/#interface-urlsearchparams

Platform coverage: all platforms

Estimated or target release: Fx53

Preference behind which this will be implemented: none

DevTools bug: no need

Do other browser engines implement this? I don't know this, yet

Tests: WPT

Security & Privacy Concerns: none



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

Re: Deprecating XUL in new UI

[smaug]

On 01/18/2017 08:28 AM, smaug wrote:

On 01/17/2017 10:51 PM, J. Ryan Stinnett wrote:

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



those looks like about reading/writing to disk, not about the cache itself, 
which should still help quite a bit with new window performance.
We did get significant performance regression when starting to use html 
for...hm, was it about:newtab or about:home or what.

And https://bugzilla.mozilla.org/show_bug.cgi?id=1286082 is only about some 
case, not all, as far as I see, but let me test.



Just tested and we seem to load for example
chrome://browser/content/browser.xul
chrome://global/content/editMenuOverlay.xul
chrome://browser/content/baseMenuOverlay.xul
chrome://browser/content/places/placesOverlay.xul
loaded chrome://layoutdebug/content/layoutdebug-overlay.xul
chrome://browser/content/report-phishing-overlay.xul
successfully when starting browser.
And once those are loaded, they don't need to be loaded again when opening new 
windows.

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

Re: Is it possible to implement "click to play" for Adobe Flash in XULRunner app?

[段垚]

Thank you very much!

It looks a bit complicated. Maybe I'd consider a pure front-end solution 
instead.



在 2017/1/14 0:06, Benjamin Smedberg 写道:
You have to manage the UI yourself. Firefox does this with a 
combination of applying an overlay to the disabled Flash which shows 
the grey UI, plus script that sets permissions and activates plugins 
appropriately. Because of e10s, that code is split between multiple 
files, but you should try to read and understand the following bits:


http://searchfox.org/mozilla-central/source/browser/modules/PluginContent.jsm 
- frame script (runs in content process)
http://searchfox.org/mozilla-central/source/browser/base/content/browser-plugins.js 
- UI script (runs in chrome process)
Binding files that set up the click-to-play overlay UI: 
http://searchfox.org/mozilla-central/source/toolkit/pluginproblem/content


Be aware that we're actively removing plugin support from the Mozilla 
platform; soon only Flash is likely to work, and after a while NPAPI 
might be removed completely. So don't get too wedded to plugin support 
in XULRunner as a long-term strategy.


--BDS


On Wed, Jan 11, 2017 at 10:01 PM, 段垚 > wrote:


Hi,

In Firefox, "click to play" can be enabled by setting pref
"plugin.state.flash" to 1.

However, when I do this in a XULRunner app, flash plugin is
disabled completely.

Is this feature unavailable to XULRunner? If so, how can I
implement it?


Thanks.


Duan Yao.


___
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: Deprecating XUL in new UI

[smaug]

On 01/17/2017 10:51 PM, J. Ryan Stinnett wrote:

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



those looks like about reading/writing to disk, not about the cache itself, 
which should still help quite a bit with new window performance.
We did get significant performance regression when starting to use html 
for...hm, was it about:newtab or about:home or what.

And https://bugzilla.mozilla.org/show_bug.cgi?id=1286082 is only about some 
case, not all, as far as I see, but let me test.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[smaug]

On 01/17/2017 12:05 AM, Dave Townsend wrote:

Trees! I knew I was forgetting something, thank you. Yeah those are things
we're going to need some sane replacements for.

AS far as XBL goes, while I suspect it works from HTML documents I think we
want to be phasing out use of XBL too for pretty much the same reasons as
XUL. Web components seem like an obvious alternative and I understand that
they are only preffed off right now. If we can have them work in chrome
documents they could be the right replacement.


The Shadow DOM implementation v0 we have in tree will be replaced with v1. 
Those aren't quite compatible in
API level. We must not pref on the current shadow DOM implementation.




On Mon, Jan 16, 2017 at 1:28 PM, Matthew N.  wrote:


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

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

Matthew

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


One of the things I've been investigating since moving back to the
desktop team is how we can remove XUL from the application as much as
possible. The benefits for doing this are varied, some obvious examples:

* XUL is a proprietary standard and we barely maintain it.
* Shallower learning curve for new contributors who may already know and
use HTML.
* HTML rendering is more optimized in the platform than XUL.
* Further integration of Servo code may require dropping XUL altogether.

The necessary first step of reducing XUL use is to stop adding any more
UI that uses XUL and here I'm talking about wholly new UI, additions to
browser.xul and other existing UI are a separate concern. What do folks
think about making this a rule for new projects in the near future?

Of course there are some features missing from HTML that make this
impossible in some cases right now. Some that I've already found:

* HTML has no support for popup panels like XUL does. The devtools team
have been working around this but they are still dependent on XUL right now.
* iframe elements don't have the same capabilities that the XUL browser
element does and we use that in some UI.
* Top level menus on OSX are currently only able to be defined with XUL
elements. This only affects UI that uses top-level windows and most of our
new UI is in-content so may be less of an issue.

What other features do we depend on in XUL that I haven't listed?

___
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev






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

Emoji and Bugzilla

[Emma Humphries]

As the BMO team announced earlier, we're going to be allowing emoji in user
inputs in Bugzilla.

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

We have not committed to a date to release this feature as it requires a
production database change which we haven't been able schedule yet.

Meanwhile, this change means that as an Bugzilla API consumer, you will
need to be ready to accept emoji in your systems.

In particular, if your client application uses MySQL, you'll need to update
your databases and tables to use utf8mb4 instead of utf8 encoding,
otherwise if you try writing strings containing emoji, they would be
truncated at the first emoji which would be a  situation. Adjust that
caveat as needed for other data stores such as Postgres.

If your application will need time to be able to support emoji, please
contact the bmo team. Otherwise we'll assume you're  with this change and
not .

Also, once we turn this feature on, some of our users will think themselves
clever and create bugs with  as the title. If the bug contains little
else than that, it's probably a  and can be closed as INVALID.

-- Emma ()
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Gijs Kruitbosch]

On 17/01/2017 17:55, Bobby Holley wrote:

On Tue, Jan 17, 2017 at 8:56 AM, Boris Zbarsky  wrote:


On 1/16/17 4:28 PM, Matthew N. wrote:


Does it just work from XHTML documents?



Yes, as far as I know.

Is our implementation of Web Components ready to replace it and riding the

trains?



No.





From the perspective of the platform, my general experience is that XBL is

much, much more of a PITA than XUL itself. I would be very skeptical of a
plan to start using some form of heavily-XBL-reliant HTML.

I have generally ambivalent feelings towards XUL, but XBL cannot die fast
enough.


As both of you are aware, I am (very) sympathetic to this sentiment, but 
we'll need a replacement of some sort. In toplevel chrome, we can in 
theory use some kind of JS framework (like React, or something else). 
However, that doesn't really solve things like the video controls (which 
we embed into content  elements).


What can we do in this space if Web Components is not the answer? Like, 
can we (and I'm thinking out loud here) build a system where we get 
handed the native anon container element in a script (js component 
createinstance + init with a param, if we need something existing to 
piggyback on) that has its own context (and ideally, some way to load 
more script)?


If there isn't a reasonable other answer, what's the rough timeframe for 
web components to be more feasible (maybe only in chrome and/or in 
native anon content (because video controls...)) ) - weeks, months, 
years, decades ? :-)


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

Re: Deprecating XUL in new UI

[Brian Grinstead]

A few things we had to handle when going through this process for the devtools 
UI:
1) Already mentioned to but for panels we added a new module that falls back to 
XUL panels for now
2) For context menu handling we we added a new module similar to the Menu API 
from Electron that falls back to  and  elements.  We didn't 
need to worry about top-level menus or overlays though.
3) Not impossible but needed a replacement for  /  elements for 
registering keyboard shortcuts.
4) Not impossible but agree with Jarda about mixing XUL and HTML flex - many of 
the bugs blocking the de-XUL meta 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1263741) were layout issues 
created when an individual UI component was converted, and finding workarounds 
can be time consuming and require trial and error.

For 1 and 2, in our case it was worth changing the frontend to use new modules 
even though they are ultimately still relying on XUL.  That let us provide an 
HTML shim when running the panel in a content tab, and hopefully will let us 
change the implementation if/when there are ways to do it without XUL.

Brian

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

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

Re: Deprecating XUL in new UI

[Kris Maglione]

On Tue, Jan 17, 2017 at 02:51:47PM -0600, J. Ryan Stinnett wrote:

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.


I've recently run into multiple bugs (mostly timing bugs) that 
only show up after we flush the prototype cache and have to do a 
fresh load, so I can say with fair certainty that it is doing 
something.

___
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: Deprecating XUL in new UI

[Jaroslav Šnajdr]

Hello Boris,

you're right - it's not XUL/HTML difference, but a chrome/content one. The
issue with React and privileged iframes was investigated here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1245921#c55

see comments 55 and on.

Jarda

On Tue, Jan 17, 2017 at 6:05 PM, Boris Zbarsky  wrote:

> On 1/16/17 4:31 PM, Jaroslav Šnajdr wrote:
>
>> - there is a difference in how events are dispatched in HTML vs XUL
>> iframes. In HTML, the capture/bubble phases are isolated inside the iframe
>> window, but in XUL, the target chain crosses the iframe boundaries.
>>
>
> I'm not aware of this behavior for XUL, nor do I see anything obvious in
> the event code that would cause such a thing to happen.  Are you sure this
> is the behavior you're seeing (as opposed to the "dispatch to the chrome
> event target when reaching a window" behavior which we _do_ have and which
> is not XUL-specific, but rather chrome-docshell specific)?
>
> -Boris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Bobby Holley]

On Tue, Jan 17, 2017 at 8:56 AM, Boris Zbarsky  wrote:

> On 1/16/17 4:28 PM, Matthew N. wrote:
>
>> Does it just work from XHTML documents?
>>
>
> Yes, as far as I know.
>
> Is our implementation of Web Components ready to replace it and riding the
>> trains?
>>
>
> No.
>


>From the perspective of the platform, my general experience is that XBL is
much, much more of a PITA than XUL itself. I would be very skeptical of a
plan to start using some form of heavily-XBL-reliant HTML.

I have generally ambivalent feelings towards XUL, but XBL cannot die fast
enough.

bholley


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

Intent to implement and ship: URLSearchParams from array or object

[Andrea Marchesini]

Summary: URLSearchParams constructor is changed in the latest URL spec.
Now it's possible to create URLSearchParams objects starting from a string,
an array and from an object.

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

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

Link to standard:
https://url.spec.whatwg.org/#interface-urlsearchparams

Platform coverage: all platforms

Estimated or target release: Fx53

Preference behind which this will be implemented: none

DevTools bug: no need

Do other browser engines implement this? I don't know this, yet

Tests: WPT

Security & Privacy Concerns: none
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Boris Zbarsky]

On 1/16/17 4:31 PM, Jaroslav Šnajdr wrote:

- there is a difference in how events are dispatched in HTML vs XUL
iframes. In HTML, the capture/bubble phases are isolated inside the iframe
window, but in XUL, the target chain crosses the iframe boundaries.


I'm not aware of this behavior for XUL, nor do I see anything obvious in 
the event code that would cause such a thing to happen.  Are you sure 
this is the behavior you're seeing (as opposed to the "dispatch to the 
chrome event target when reaching a window" behavior which we _do_ have 
and which is not XUL-specific, but rather chrome-docshell specific)?


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

Re: Deprecating XUL in new UI

[Boris Zbarsky]

On 1/16/17 4:28 PM, Matthew N. wrote:

Does it just work from XHTML documents?


Yes, as far as I know.


Is our implementation of Web Components ready to replace it and riding the 
trains?


No.

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

Re: Deprecating XUL in new UI

[Brian Grinstead]

You can still use dtd files in XHTML as long as it’s chrome-privileged.  A lot 
of the about pages are doing this (aboutNetError.xhtml and others: 
https://dxr.mozilla.org/mozilla-central/search?q=path%3Axhtml+dtd).

Brian

> On Jan 17, 2017, at 3:34 AM, zbranie...@mozilla.com wrote:
> 
> One more thing that XUL gives us is L10n.
> 
> With HTML, we can use .properties to load localization resources and inject 
> them into HTML, but I believe this to be a very inelegant solution with a 
> surprisingly high risk of bugs.
> 
> We do have an l10n framework called L20n that is supposed to replace DTD and 
> works in raw XUL and HTML binding elements to l10n messages with 
> `data-l10n-id` attribute.
> 
> Our plan was to target post-quantum release to refactor the XUL code to 
> switch from DTD to L20n, but we could also just introduce the new approach 
> and use it for new code already, while waiting for post-quantum to transition 
> the old code.
> 
> zb.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

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

Re: Deprecating XUL in new UI

[zbraniecki]

One more thing that XUL gives us is L10n.

With HTML, we can use .properties to load localization resources and inject 
them into HTML, but I believe this to be a very inelegant solution with a 
surprisingly high risk of bugs.

We do have an l10n framework called L20n that is supposed to replace DTD and 
works in raw XUL and HTML binding elements to l10n messages with `data-l10n-id` 
attribute.

Our plan was to target post-quantum release to refactor the XUL code to switch 
from DTD to L20n, but we could also just introduce the new approach and use it 
for new code already, while waiting for post-quantum to transition the old code.

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