Re: Soft code freeze for Firefox 73 starts January 2

[Ryan VanderMeulen]

Hi all,

The Nightly version has been bumped to 74 and with that, the soft freeze
has ended.

Thanks,
Ryan

On Tue, Dec 31, 2019 at 1:42 PM Liz Henry (:lizzard) 
wrote:

> Hello everyone,
>
> We're nearing the end of the Nightly 73 cycle as well as the end of the
> year and the decade!
>
> In order to avoid invalidating the testing we get out of late Nightly and
> to ensure that we can roll out Beta 73 to a wider audience with confidence,
> we'd like to ask that any risky changes be avoided from January 2 until
> after the version bump
> to 74 on January 6.
>
> Some reminders for the soft code freeze period:
>
> Do:
> - Be ready to back out patches that cause crash spikes, new crashes,
> severe regressions
> - Monitor new regressions and escalate merge blockers
> - Support release management by prioritizing fixing of merge blockers
>
> Do Not:
> - Land a risky patch or a large patch
> - Land new features (that affect the current Nightly version) — be mindful
> that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can lead to
> unexpected CI results
> - Flip prefs that enable new Features that were untested in the Nightly
> cycle
> - Plan to kick off new experiments that might impact a feature's merge
> readiness
>
> Please let us know if you have any questions/concerns.
>
> Thanks,
>
> Liz & the release management team
>
> --
> 
> Liz Henry (:lizzard)
> Firefox Release Manager
> lhe...@mozilla.com
> ___
> 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

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

[Mihai Boldan]

Hello,

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

Bugs logged by Desktop Release QA in the last 7 days:
*
*Firefox: Downloads Panel
* NEW - https://bugzil.la/1606295 - [Ubuntu] Opening containing folder 
will open file manager in background not foreground

Firefox: File Handling
* NEW - https://bugzil.la/1606797 - Two external application windows 
will appear when a phone number is accessed on Outlook-People

Core: Graphics
* NEW - https://bugzil.la/1606316 - About Firefox Nightly window not 
rendered correctly on integrated GPU's while Fission is enabled

Toolkit: Themes
* NEW - https://bugzil.la/1606431 - [Win] Add button (active state) is 
only partially highlighted when using Tab navigation inside New Bookmark 
panel


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


Regards,
Mihai Boldan


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

Re: PSA: You can use UTF8String from WebIDL

[Jan de Mooij]

On Mon, Jan 6, 2020 at 2:51 AM Emilio Cobos Álvarez 
wrote:

> If it's not, it could be optimized teaching JSStrings to store UTF-8
> instead of / on top of Latin1 or such, or returning more information
> from the callee, but I don't know how easy would be the first (IIRC
> we're out of JSString bits), and how worth it would be the second.
> Feedback here from JS engine hackers would be much appreciated.
>

Supporting UTF8 JSStrings natively would be quite a lot of work. I added
Latin1 strings a few years ago but Latin1 is a bit simpler than UTF8
because most algorithms could be templatized to work with either char type.
If most of your UTF8 strings are (7-bit) ASCII, it might make sense
short-term to use a Latin1 external string to avoid copies.

One possible approach would be to treat UTF8 JSStrings somewhat similar to
ropes: initially most places working with JSString characters would end up
converting from UTF8 to Latin1/TwoByte but after that we could
(incrementally) optimize these functions to work with UTF8 strings directly
where possible.

Jan

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

Re: PSA: You can use UTF8String from WebIDL

[Emilio Cobos Álvarez]

On 1/6/20 11:12 AM, Jan de Mooij wrote:
On Mon, Jan 6, 2020 at 2:51 AM Emilio Cobos Álvarez > wrote:


If it's not, it could be optimized teaching JSStrings to store UTF-8
instead of / on top of Latin1 or such, or returning more information
from the callee, but I don't know how easy would be the first (IIRC
we're out of JSString bits), and how worth it would be the second.
Feedback here from JS engine hackers would be much appreciated.


Supporting UTF8 JSStrings natively would be quite a lot of work. I added 
Latin1 strings a few years ago but Latin1 is a bit simpler than UTF8 
because most algorithms could be templatized to work with either char 
type. If most of your UTF8 strings are (7-bit) ASCII, it might make 
sense short-term to use a Latin1 external string to avoid copies.


Yeah, most of them are ASCII, but it's not easy to track that that the 
output is ASCII... It'd still be doable though.


One possible approach would be to treat UTF8 JSStrings somewhat similar 
to ropes: initially most places working with JSString characters would 
end up converting from UTF8 to Latin1/TwoByte but after that we could 
(incrementally) optimize these functions to work with UTF8 strings 
directly where possible.


Yeah, I suspect the most common operations that are done on CSS strings 
are comparing them, passing them back to the OM, appending to them, and 
parse{Int,Float} them (with various variants of split(), substr() and 
such involved), so yeah that sounds viable...


Anyhow I need to do some profiling for various cases here to see what 
amount of complexity is worth taking for this.


Thanks a lot!

 -- Emilio


Jan

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



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

Re: PSA: You can use UTF8String from WebIDL

[Bobby Holley]

Thank you (and all the dependent authors) for working on this! String
conversion overhead is so silly in theory yet so difficult to eliminate in
practice. It's great to see us investing in the right architecture to
enable these optimizations across the board.

On Sun, Jan 5, 2020 at 5:51 PM Emilio Cobos Álvarez 
wrote:

> If you need UTF-8 inputs from WebIDL (for example if you are passing the
> input to Rust), chances are you're doing an extra copy from JS.
>
> In bug 1449861 I've added an UTF8String so that you can convert a
> JSString to UTF-8 in a single operation, instead of going through UTF-16.
>
> I can't think if any reason not to use it in places where you take a
> USVString / DOMString argument and you turn it internally to utf-8 via
> NS_ConvertUTF16toUTF8.
>
> I'd be a bit more wary of stuff that _returns_ UTF-8 output for now, at
> least for very-performance-sensitive code. I need to do some profiling
> and such to see if it's worth it as-is for CSSOM.
>
> If it's not, it could be optimized teaching JSStrings to store UTF-8
> instead of / on top of Latin1 or such, or returning more information
> from the callee, but I don't know how easy would be the first (IIRC
> we're out of JSString bits), and how worth it would be the second.
> Feedback here from JS engine hackers would be much appreciated.
>
> It'd be pretty great to eventually be able to share UTF-8 strings with
> JS the same way we can share strings with C++ via nsStringBuffer... But
> again that's probably follow-up work.
>
> Anyhow, I hope you find it useful. This is built on top of various great
> work by Henri Sivonen, Jeff Walden and others, and the always-helpful
> reviews of Boris Zbarsky when dealing with WebIDL. So in the end I
> mostly took care of doing the plumbing :-).
>
> Cheers,
>
>   -- Emilio
> ___
> 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