Re: mozilla::Hash{Map,Set}

[Nicholas Nethercote]

On Fri, Aug 17, 2018 at 3:31 AM, Eric Rahm  wrote:

>
> nsTHashTable is just a templated wrapper around PLDHashTable. For
> reference we also have nsDataHashtable, nsClassHashtable,
> nsRefPtrHashtable, nsInterfaceHashtable [1] all of which are rather
> convenient wrappers around PLDHashTable. These have also been implemented
> in such a way that the templates have lower code size overhead (thanks
> froydnj!). I somewhat prefer their interfaces to mfbt::HashMap (default
> infallible, plenty of predefined hashers, nice lookup for add semantics,
> etc), but to each their own.
>

About that last sentence:

- Default infallible: true, although I removed the init() function from
mozilla::Hash{Map,Set} (by making allocation lazy, waiting until first
insertion) so at least you don't have to worry about that any more.

- Plenty of predefined hashes: mozilla::Hash{Map,Set} does the right thing
by default if your key is an integer, pointer, UniquePtr, float, or double.
There's also the predefined CStringHasher for C string keys. Nothing at the
moment for RefPtr or nsCOMPtr, though.

- Nice lookup for add semantics: mozilla::Hash{Map,Set} has this too. You
use put() for an unconditional insertion, or lookupForAdd() + add() for a
conditional insertion.

If you ever looked at the old js::Hash{Map,Set} and found it confusing,
it's worth taking another look at mozilla::Hash{Map,Set}, because I
improved the high-level and per-method documentation a lot. I also
completely reordered the classes code so that operations are grouped
logically and are much easier to find.

Additionally we've been thinking about implementing a better hash algorithm
> such as round-robin hashing [2] , I'm not sure if that would work w/
> mfbt::HashMap, but it would be nice to implement it in one place rather
> than two.
>

The main takeaway I got from doing the microbenchmarks in bug  1477622 was
that Robin Hood hashing is probably on a minor improvement. It's probably
worth doing, but:

(a) for C++ hash tables, full templating and inlining makes the biggest
difference;
(b) for Rust hash tables (which already use Robin Hood), choosing a fast
hash function makes the biggest difference.

Point (a) was the reason I decided to move js::Hash{Map,Set} into MFBT.

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

Intent to unship "namedanchor" keyword from nsIHTMLEditor.createElementWithDefaults(), nsIHTMLEditor.getSelectedElement() and nsIHTMLEditor.getElementOrParentByTagName()

[Masayuki Nakano]

nsIHTMLEditor::CreateElementWithDefaults(), 
nsIHTMLEditor::GetSelectedElement() and 
nsIHTMLEditor::nsIHTMLEditor::GetElementOrParentByTagName() treat 
"namedanchor" as  element. However, it seems that this is 
legacy name since there is another name, "anchor", and only "anchor" is 
used in comm-central and BlueGriffon. Due to not defined as an Atom, it 
does not make sense to keep supporting this value.


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

The first release of this change will be 63.

--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: mozilla::Hash{Map,Set}

[Nicholas Nethercote]

On Fri, Aug 17, 2018 at 3:10 AM, Kris Maglione 
wrote:

>
> It would probably worth converging the APIs, if only because the
> nsTHashtable APIs are arcane and antiquated. But it's easier said than
> done. There are a lot of consumers of all of the hashtable APIs, and the
> code is... not very easy to work with.
>

Also, the APIs are *very* different.

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

Fission MemShrink Newsletter #2

[Eric Rahm]

Hi Folks!

The Fission MemShrink project has been chugging along quite nicely and a
ton of progress has been made over the past month. There's been a large
focus on reducing the JS memory usage and we've managed to drop the base
content JS measure

by ~1.1MB (17%) [1]:

[image:
https://screenshotscdn.firefoxusercontent.com/images/c5046573-91bd-4ca1-98db-6290777e70c4.png]

Additionally we've started looking at the overhead of our many threads
 [2], drafted up some
ideas on reducing relocation overhead by adopting a fork server
 on linux/mac [3],
and we're looking at reducing the overhead of per process font related data
 [4].

Below is a sampling of the bugs that have improved memory usage over the
past month, apologies if I left any off! Please feel free to point out
other improvements. All numbers are *per content process*.

*JS improvements*

   - In a great example of every little bit counts, *Kris Maglione* reduced
   memory usage by *405KB* in various bugs that made us lazily load JS
   content (Bug 1472491
   , Bug 1473631
   , Bug 1474139
   , Bug 1474155
   , Bug 1479241
   , Bug 1479245
   , Bug 1479309
   , Bug 1479310
   , Bug 1479312
   , Bug 1479313
   , Bug 1479318
   , Bug 1480319
   , Bug 1480327
   , Bug 1483363
   )
   - Kris also reduced memory usage by *494KB* by getting rid of
   MessageManager globals (Bug 1480244
   )
   - *Felipe Gomes* reduced memory usage by *95KB* by lazily loading JS
   content (Bug 1369466
   , Bug 1470324
   )
   - *Mike Kaply* reduced memory usage by *65KB* by converting an add-on to
   in tree telemetry (Bug 1475571
   )
   - *Dão Gottwald* reduced memory uasge by *57KB* by lazily generating
   thumbnails for the Ctrl+Tab panel (Bug 1481321
   )
   - *Nick Nethercote* reduced memory usage by *44KB* by making
   mozilla::HashMaps lazily allocate their storage (Bug 1481998
   )
   - *Benjamin Bouvier* reduced memory usage by *25KB* by removing SIMD.js (Bug
   1416723 )

*Threading Overhead*

   - Kris added measurements for thread stacks across platforms (Bug 1475899
   , Bug 1476405
   , Bug 1477512)
   
   - Kris reduced memory usage on Linux by *~3MB* (that's megabytes!) by
   changing our default stack size (Bug 1476828
   )
   - *Eric Rahm* (this author) reduced memory usage by *50KB* by reducing
   the amount of networking threads (Bug 1448034
   )
   - *Xidorn Quan* committed an upstream Rust patch (rust-lang/rust#52847
   ) to fix how stack sizes
   are set on windows after Kris' initial investigation (Bug 1479250
   )

*Font Overhead*

   - The winner of biggest improvement with the smallest change goes to *Lee
   Salzman* who reduced memory usage on OSX by *10MB* by reducing the skia
   glyph cache (Bug 1258781
   )

*Lessons learned*

Small fixes add up, removing dead code not only helps code quality but can
save memory, adding measurements is important, caches can be easy targets.
If you know of a cache we might tweak please file a bug to consider
reducing it.

-e

[1]
https://treeherder.mozilla.org/perf.html#/graphs?timerange=2592000=autoland,1684872,1,4
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1476432
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1470591
[4] 

Re: Workaround for building with Visual Studio 15.7+

[Jeff Gilbert]

FWIW, I found that building with clang-cl works fine out-of-the-box
with 15.7.x, and the Installer tells me that I don't have the 15.6
toolset installed. YMMV, but I've found that clang-cl builds Just Work
with 15.7.

On Thu, Aug 16, 2018 at 5:23 AM, Gabriele Svelto  wrote:
>  Hello all,
> being among those unfortunate enough to have updated Visual Studio
> before realizing that the most recent version cannot be used to build
> Firefox, I was faced with the prospect of reinstalling the whole
> monstrosity - which takes forever - or finding a workaround. As it turns
> out I found a clunky yet simple one:
>
> - Launch the Visual Studio Installer, the click on the "modify" button
>
> - Go into the "Individual components" and select the "VC++ 2017 version
> 15.6 v14.13 toolset" component
>
> - Launch the installation
>
> - Modify build/moz.configure/toolchain.configure by manually setting the
> tools_version string in [1] to the value '14.13.26128'
>
> - You're done! Both a clang-cl and a msvc should now pick up the old
> tooling and work properly (provided you have the right Windows SDK).
>
> I couldn't find a way to override this via mozconfig options or
> environment variables but if there is a way to do this without modifying
> the sources I'd like to hear it.
>
>  Gabriele
>
> [1]
> https://searchfox.org/mozilla-central/rev/5dbfd833bbb114afe758db4d4bdbc5b13bcc33ef/build/moz.configure/toolchain.configure#584
>
>
> ___
> 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 '-webkit-appearance' and changes to '-moz-appearance' values

[Eric Shepherd (Sheppy)]

Those notes should also be useful for the docs team if we need to document
this stuff before it makes it into a spec.

On Wed, Aug 15, 2018 at 6:18 PM Mats Palmgren  wrote:

> On 8/14/18 12:52 AM, Jonathan Watt wrote:
> > On 08/08/2018 21:08, Boris Zbarsky wrote:
> >> Are we writing down something that could get turned into a spec?
> >
> > I've got a bunch of messy notes that I hope will be of some use for
> that, but
> > no, so far I have not attempted to create draft spec text to replace the
> text in
> > CSS UI 4.
>
> It'd be awesome if you could write this down somewhere while you
> have the details somewhat fresh in your mind.  I'd be happy to
> contribute what I know about this too.
>
> Those notes would be an excellent starting point for a discussion
> with other vendors about speccing this property, which I believe
> is necessary if we're going to converge UAs to something that
> is "compatible".
>
>
> /Mats
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>


-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: mozilla::Hash{Map,Set}

[Kris Maglione]

On Thu, Aug 16, 2018 at 09:07:57AM -0400, Alex Gaynor wrote:

Similarly, would it make sense to consolidate the APIs, as much as
possible, if the primary differences are around implementation details like
"how much is templated/inlined"?


It would probably worth converging the APIs, if only because the 
nsTHashtable APIs are arcane and antiquated. But it's easier 
said than done. There are a lot of consumers of all of the 
hashtable APIs, and the code is... not very easy to work with.



On Wed, Aug 15, 2018 at 5:39 AM Nicholas Nethercote 
wrote:


Hi,

I recently moved Spidermonkey's js::Hash{Map,Set} classes from
js/public/HashTable.h into mfbt/HashTable.h and renamed them as
mozilla::Hash{Map,Set}. They can now be used throughout Gecko.

(js/public/HashTable.h still exists in order to provide renamings of
mozilla::Hash{Map,Set} as js::Hash{Map,Set}.)

Why might you use mozilla::Hash{Map,Set} instead of PLDHashTable (or
nsTHashtable and other descendants)?

- Better API: these types provide proper HashMap and HashSet instances, and
(in my opinion) are easier to use.

- Speed: the microbenchmark in xpcom/rust/gtest/bench-collections/Bench.cpp
shows that mozilla::HashSet is 2x or more faster than PLDHashTable. E.g.
compare "MozHash" against "PLDHash" in this graph:


https://treeherder.mozilla.org/perf.html#/graphs?timerange=604800=mozilla-central,1730159,1,6=mozilla-central,1730162,1,6=mozilla-central,1730164,1,6=mozilla-central,1732092,1,6=mozilla-central,1730163,1,6=mozilla-central,1730160,1,6

Bug 1477627 converted a hot hash table from PLDHashTable to
mozilla::HashSet and appears to have sped up cycle collection in some cases
by 7%. If you know of another PLDHashTable that is hot, it might be worth
converting it to mozilla::HashTable.

Both mozilla::Hash{Map,Set} and PLDHashTable use the same double-hashing
algorithm; the speed difference is due to mozilla::HashSet's extensive use
of templating and inlining. The downside of this is that mozilla::HashSet
will increase binary size more than PLDHashTable.

There are overview comments at the top of mfbt/HashTable.h, and the classes
themselves have more detailed comments about every method.

Nick
___
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


--
Kris Maglione
Senior Firefox Add-ons Engineer
Mozilla Corporation

He who joyfully marches to music in rank and file has already earned
my contempt.  He has been given a large brain by mistake, since for
him the spinal cord would suffice.
--Albert Einstein

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

Re: mozilla::Hash{Map,Set}

[Eric Rahm]

On Thu, Aug 16, 2018 at 6:07 AM, Alex Gaynor  wrote:

> Would it make sense to consider giving nsTHashtable and PLDHashTable
> different names? Right now the names suggest that we have 3 general purpose
> hash tables, but it might be easier if the names better suggested their
> purpose, e.g. PLDHashTable -> MinimalCodeSizeHashTable (I'm sure we can do
> better than that).
>

nsTHashTable is just a templated wrapper around PLDHashTable. For reference
we also have nsDataHashtable, nsClassHashtable, nsRefPtrHashtable,
nsInterfaceHashtable [1] all of which are rather convenient wrappers around
PLDHashTable. These have also been implemented in such a way that the
templates have lower code size overhead (thanks froydnj!). I somewhat
prefer their interfaces to mfbt::HashMap (default infallible, plenty of
predefined hashers, nice lookup for add semantics, etc), but to each their
own.

[1]
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Guide/Hashtables



> Similarly, would it make sense to consolidate the APIs, as much as
> possible, if the primary differences are around implementation details like
> "how much is templated/inlined"?
>
>
Really we just have PLDHashTable for historical reasons, not because of
text size. I'm not sure we even want to keep PLDHashTable at all. We *have*
found some issues where there's higher memory overhead due to the way our
template wrappers pad their key structures and having a much lower level,
but slightly annoying to use hashtable ended up being a good thing.
Additionally we've been thinking about implementing a better hash algorithm
such as round-robin hashing [2] , I'm not sure if that would work w/
mfbt::HashMap, but it would be nice to implement it in one place rather
than two.

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1402910

-e



> Alex
>
>
> On Wed, Aug 15, 2018 at 5:39 AM Nicholas Nethercote <
> n.netherc...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I recently moved Spidermonkey's js::Hash{Map,Set} classes from
> > js/public/HashTable.h into mfbt/HashTable.h and renamed them as
> > mozilla::Hash{Map,Set}. They can now be used throughout Gecko.
> >
> > (js/public/HashTable.h still exists in order to provide renamings of
> > mozilla::Hash{Map,Set} as js::Hash{Map,Set}.)
> >
> > Why might you use mozilla::Hash{Map,Set} instead of PLDHashTable (or
> > nsTHashtable and other descendants)?
> >
> > - Better API: these types provide proper HashMap and HashSet instances,
> and
> > (in my opinion) are easier to use.
> >
> > - Speed: the microbenchmark in xpcom/rust/gtest/bench-
> collections/Bench.cpp
> > shows that mozilla::HashSet is 2x or more faster than PLDHashTable. E.g.
> > compare "MozHash" against "PLDHash" in this graph:
> >
> >
> > https://treeherder.mozilla.org/perf.html#/graphs?
> timerange=604800=mozilla-central,1730159,1,6&
> series=mozilla-central,1730162,1,6=mozilla-
> central,1730164,1,6=mozilla-central,1732092,1,6&
> series=mozilla-central,1730163,1,6=mozilla-central,1730160,1,6
> >
> > Bug 1477627 converted a hot hash table from PLDHashTable to
> > mozilla::HashSet and appears to have sped up cycle collection in some
> cases
> > by 7%. If you know of another PLDHashTable that is hot, it might be worth
> > converting it to mozilla::HashTable.
> >
> > Both mozilla::Hash{Map,Set} and PLDHashTable use the same double-hashing
> > algorithm; the speed difference is due to mozilla::HashSet's extensive
> use
> > of templating and inlining. The downside of this is that mozilla::HashSet
> > will increase binary size more than PLDHashTable.
> >
> > There are overview comments at the top of mfbt/HashTable.h, and the
> classes
> > themselves have more detailed comments about every method.
> >
> > Nick
> > ___
> > 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

landing --enable-node by default shortly: today, Thursday, Aug _16th_

[dmosedale]

It has been pointed out that I made a mistake in my previous announcements -- 
today, Thursday, is August 16th, not August 17th.  

Sorry about that!

I'm still going to go ahead and land this change shortly, because doing it now 
gives us more time before soft-freeze to shake out any issues that turn up.  I 
also suspect, given the number of recent previous announcements, that most 
folks who want to try and run `mach bootstrap --no-system-changes` ahead of 
time are likely to have already done so.

https://groups.google.com/forum/#!topic/mozilla.dev.platform/nNS961NjbVk has 
the most recent announcement, should you need any more details.

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

Re: mozilla::Hash{Map,Set}

[Alex Gaynor]

Would it make sense to consider giving nsTHashtable and PLDHashTable
different names? Right now the names suggest that we have 3 general purpose
hash tables, but it might be easier if the names better suggested their
purpose, e.g. PLDHashTable -> MinimalCodeSizeHashTable (I'm sure we can do
better than that).

Similarly, would it make sense to consolidate the APIs, as much as
possible, if the primary differences are around implementation details like
"how much is templated/inlined"?

Alex


On Wed, Aug 15, 2018 at 5:39 AM Nicholas Nethercote 
wrote:

> Hi,
>
> I recently moved Spidermonkey's js::Hash{Map,Set} classes from
> js/public/HashTable.h into mfbt/HashTable.h and renamed them as
> mozilla::Hash{Map,Set}. They can now be used throughout Gecko.
>
> (js/public/HashTable.h still exists in order to provide renamings of
> mozilla::Hash{Map,Set} as js::Hash{Map,Set}.)
>
> Why might you use mozilla::Hash{Map,Set} instead of PLDHashTable (or
> nsTHashtable and other descendants)?
>
> - Better API: these types provide proper HashMap and HashSet instances, and
> (in my opinion) are easier to use.
>
> - Speed: the microbenchmark in xpcom/rust/gtest/bench-collections/Bench.cpp
> shows that mozilla::HashSet is 2x or more faster than PLDHashTable. E.g.
> compare "MozHash" against "PLDHash" in this graph:
>
>
> https://treeherder.mozilla.org/perf.html#/graphs?timerange=604800=mozilla-central,1730159,1,6=mozilla-central,1730162,1,6=mozilla-central,1730164,1,6=mozilla-central,1732092,1,6=mozilla-central,1730163,1,6=mozilla-central,1730160,1,6
>
> Bug 1477627 converted a hot hash table from PLDHashTable to
> mozilla::HashSet and appears to have sped up cycle collection in some cases
> by 7%. If you know of another PLDHashTable that is hot, it might be worth
> converting it to mozilla::HashTable.
>
> Both mozilla::Hash{Map,Set} and PLDHashTable use the same double-hashing
> algorithm; the speed difference is due to mozilla::HashSet's extensive use
> of templating and inlining. The downside of this is that mozilla::HashSet
> will increase binary size more than PLDHashTable.
>
> There are overview comments at the top of mfbt/HashTable.h, and the classes
> themselves have more detailed comments about every method.
>
> Nick
> ___
> 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: Some of the Phabricator review requests don't show up in Bugzilla dashboard

[Andreas Tolfsen]

Also sprach Mike Hommey:

> Also, for reviewers, be aware that phabricator reviews don't count
> in the red counter on the top right of bugzilla, don't appear in
> the associated drop-down menu, and don't appear in "My requests"
> either.

This is a bit surprising.  I just discovered I had two reviews
waiting for me that had been sitting there for four days.

Could we do anything to have them included in the ‘Requests’ queue
in Bugzilla?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Workaround for building with Visual Studio 15.7+

[Gabriele Svelto]

 Hello all,
being among those unfortunate enough to have updated Visual Studio
before realizing that the most recent version cannot be used to build
Firefox, I was faced with the prospect of reinstalling the whole
monstrosity - which takes forever - or finding a workaround. As it turns
out I found a clunky yet simple one:

- Launch the Visual Studio Installer, the click on the "modify" button

- Go into the "Individual components" and select the "VC++ 2017 version
15.6 v14.13 toolset" component

- Launch the installation

- Modify build/moz.configure/toolchain.configure by manually setting the
tools_version string in [1] to the value '14.13.26128'

- You're done! Both a clang-cl and a msvc should now pick up the old
tooling and work properly (provided you have the right Windows SDK).

I couldn't find a way to override this via mozconfig options or
environment variables but if there is a way to do this without modifying
the sources I'd like to hear it.

 Gabriele

[1]
https://searchfox.org/mozilla-central/rev/5dbfd833bbb114afe758db4d4bdbc5b13bcc33ef/build/moz.configure/toolchain.configure#584



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Soft code freeze for Firefox 63 starts August 23

[Pascal Chevrel]

Hello,

This is a reminder that the Nightly Soft Freeze is now less than a week
away. Please be mindful of any large or risky patches targeting Firefox
63 before the soft freeze begins and we begin merges to the Beta branch.

Thanks!

Pascal


Le 09/08/2018 à 15:18, Pascal Chevrel a écrit :
> Hi all,
> 
> On August 23, we will be merging Firefox 63 from mozilla-central to beta
> for the first time. In order to avoid invalidating the testing we get
> out of late Nightly and the early Developer Edition builds and to ensure
> that we can roll out Beta 63 to a wider audience with confidence, we'd
> like to ask that any risky changes be avoided from August 23 until after
> the version bump to 64 on September 4th.
> 
> Some reminders for the soft code freeze period:
> 
> Do:
> - Be ready to backout 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 affects 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 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,
> 
> Release Management Team
> 
> https://wiki.mozilla.org/Release_Management/Release_Process#Nightly_soft_code_freeze
> 


-- 
Pascal Chevrel
Staff Project Manager - Firefox Nightly
https://wiki.mozilla.org/Nightly
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Some of the Phabricator review requests don't show up in Bugzilla dashboard

[Mike Hommey]

On Thu, Aug 16, 2018 at 10:19:37AM +0100, Andreas Tolfsen wrote:
> Also sprach Mike Hommey:
> 
> > Also, for reviewers, be aware that phabricator reviews don't count
> > in the red counter on the top right of bugzilla, don't appear in
> > the associated drop-down menu, and don't appear in "My requests"
> > either.
> 
> This is a bit surprising.  I just discovered I had two reviews
> waiting for me that had been sitting there for four days.
> 
> Could we do anything to have them included in the ‘Requests’ queue
> in Bugzilla?

Note they do appear in "My dashboard". But as per the thread starter,
that doesn't contain all review requests anyways, so at the moment, the
best thing to do is to check https://phabricator.services.mozilla.com/

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

Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default

[Masayuki Nakano]

We put off to change this until we get enough telemetry data.

Now, we have a lot of data in Beta 62 users.  That indicates that each 
specific UI is rarely shown (< 0.5% of all HTMLEditor instances). 
However, according to operation count per HTMLEditor instance, some of 
them may be used by only a few users intentionally.


Currently, I plain:
- 63 disables the UIs by default only on Nightly and Early Beta.
- 64 disables the UIs by default on all channels.

Then, we'll provide new prefs to enable them by default forcibly. This 
allows us to collect telemetry data from testers even before web apps 
enable the UIs with execCommand explicitly.


If we'll get new telemetry data of 62 Release and it indicates we 
shouldn't change our behavior, we should cancel the changes before 
shipping the 64 release.


See the detail of current telemetry result here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1452538#c19

On 2018/04/05 15:58, Masayuki Nakano wrote:

This incompatibility is pointed by W3C's Editing API WG:
https://github.com/w3c/editing/issues/171

Gecko has some specific editing UI of HTML editor.
1. Resiziers of , , absolute positioned elements.
2. Adding new table row/column from buttons.
3. Removing existing table row/column from buttons.
4. Grabber to move absolute positioned element.

Currently, all of those UIs are not implemented by the other browsers. 
However, they are available in Gecko by default.


Therefore, web app developers need to disable those features with:
document.execCommand("enableObjectResizing",
  false, false); // #1
document.execCommand("enableInlineTableEditing",
  false, false); // #2 and #3

So, if web apps don't call them, only Firefox users can modify  or 
 elements as unexpected for their developers.


Additionally, web apps cannot disable only #4.

So, for solving this incompatibility issue, we should:
* Disable those UI by default
* But allow to enable those UI for backward compatibility
* Add new command "enableAbsolutePositionEditing" command for allowing 
to enable #4


I'm working on this incompatibility issue in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1449564



--
Masayuki Nakano 
Software Engineer, Mozilla

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

Re: Some of the Phabricator review requests don't show up in Bugzilla dashboard

[Mike Hommey]

On Wed, Aug 15, 2018 at 04:53:22PM +0300, smaug wrote:
> Hi all,
> 
> I think it is good to let people know that some of the review requests in 
> Phabricator don't show up in Bugzilla.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1482110
> 
> 
> 
> So, if some review seems to take too much time, better to ping the requestee.

Also, for reviewers, be aware that phabricator reviews don't count in
the red counter on the top right of bugzilla, don't appear in the
associated drop-down menu, and don't appear in "My requests" either.

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

Changes in XPCOM string encoding conversions

[Henri Sivonen]

I've made changes to encoding conversions between XPCOM strings. Here
are the important bits of info:

 * The conversions are now generally faster, so processing text as
UTF-8 should be considered more appropriate than before even if there
exists a case where the data needs to be passed to a UTF-16 consumer.

 * There are now faster paths in Rust for appending or assigning 
to nsAString. If you have an , please use the *_str() methods
instead of the *_utf8() methods on nsAString in Rust. (That is, the
*_str() methods make use of the knowledge that the input is guaranteed
to be valid UTF-8.)

 * I'd like to make the UTF-16 to Latin1 (the function names say ASCII
instead of Latin1 for legacy reasons) conversion assert in debug
builds if the input isn't in the Latin1 range, so if you have a
mostly-ASCII UTF-16 string that you want to printf for logging and
don't care about what happens to non-ASCII, please convert to UTF-8 as
your "I don't care about non-ASCII" conversion.

 * The conversions between UTF-16 and UTF-8 in both directions now
implement spec-compliant REPLACEMENT CHARACTER generation if the input
UTF isn't valid. Previously, the output got truncated. This is not to
say that it's now OK to be less diligent about UTF validity but to say
that you can't rely on the old truncation behavior.

 * There are now conversions between UTF-8 and Latin1 to allow for
more efficient interaction with UTF-8 and SpiderMonkey strings and DOM
text nodes going forward.

 * The conversions no longer accept zero-terminated C-style strings.
The cost of strlen() is now made visible to the caller by requiring
the caller to wrap C-style strings with mozilla::MakeStringSpan().
(Please avoid C-style strings. Strings that know their length are
nice. This change wasn't made in order to make the use of C-style
string hard, though, but in order to avoid clang complaining about
ambiguous overloads.)

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

Re: mozilla::Hash{Map,Set}

[Kris Maglione]

On Wed, Aug 15, 2018 at 07:28:26PM -0400, Ehsan Akhgari wrote:

On Wed, Aug 15, 2018 at 5:39 AM Nicholas Nethercote 
wrote:

Bug 1477627 converted a hot hash table from PLDHashTable to
mozilla::HashSet and appears to have sped up cycle collection in some cases
by 7%. If you know of another PLDHashTable that is hot, it might be worth
converting it to mozilla::HashTable.



Do you have any good suggestions of how to find such candidates?  One thing
that came to my mind was that the BHR data may be a useful source of
insight for this...  <
https://arewesmoothyet.com/?category=all=512_2048=explore=c8e925752fc94f78af9349665aad14c7=PLDHashTable%3A%3ASearchTable=0>
(for content processes, for example) suggests a few hashtables based on a
very quick skimming which aren't surprising to me (things like
nsHTMLDocument::mIdentifierMap, some XPCOM component manager hashtables,
memory reporter hashtables, some font hashtables, the preferences
hashtable, sEventListenerManagersHash, mJSHolderMap, etc.


Note I'm planning to replace most of the component manager hashtables with 
static hashtables (bug 1478124), so those probably aren't great candidates 
just yet.

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