r=jdescottes
turns out we were incorrectly passing the threadClient to the environmentClient while
instantiating in one of the tests. It worked before because the threadClient exposed the API surface
of the debugger-client.
Differential Revision: https://phabricator.services.mozilla.com/D32685
--HG--
extra : moz-landing-system : lando
Code here explicitly references lastElementChild inside a toolbarbutton
but it doesn't have any tests so it wasn't caught when bug 1519577 landed :(
Differential Revision: https://phabricator.services.mozilla.com/D33104
--HG--
extra : moz-landing-system : lando
We've had a constant of 10 hard-coded there since early days.
Turning it into a configurable number allows us to easier tune it and
debug related issues.
Differential Revision: https://phabricator.services.mozilla.com/D32761
--HG--
extra : moz-landing-system : lando
This field of js::DebugScript is a count of the number of Debugger.Frames with
onPop handlers that apply to the given script, and its name should reflect that
more directly. All accessors and mutators renamed accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D32269
--HG--
extra : moz-landing-system : lando
The present JSScript::setNewStepMode method deals with both increments and
decrements. This provides a single site from which to call
BaselineScript::toggleDebugTraps. But it also checks whether it should free the
DebugScript, which is only needed when we're decrementing, and requires
incrementStepModeCount to furnish a FreeOp which is never needed.
On the balance, removing setNewStepMode altogether and letting
JSScript::incrementStepModeCount and decrementStepModeCount each specialize in
building things up or tearing things down seems cleaner, even if both need to
call toggleDebugTraps.
Differential Revision: https://phabricator.services.mozilla.com/D32268
--HG--
extra : moz-landing-system : lando
I _think_ most of the sizes that get here are going to be equivalent to
mRect.Size(), but that seems really hard to prove.
Differential Revision: https://phabricator.services.mozilla.com/D32754
--HG--
extra : moz-landing-system : lando
I need to profile this a bit more, but talos was pretty happy about this, and it
solves the known performance issues here such as the test-case from bug 1483963
for example. This also gets rid of a bunch of unsafe code which is nice.
This still keeps the same GC scheme, removing the key from the hashmap when
needed. I kept those as release assertions, but should probably be turned into
debug-only assertions.
Differential Revision: https://phabricator.services.mozilla.com/D6801
--HG--
extra : moz-landing-system : lando
The current situation is suboptimal, where we have the same goop
repeated in multiple files, and where things kinda sorta work out fine
thanks to the linker for files that would have been forbidden, except
when the linker doesn't do its job, which apparently happen on
mingwclang builds.
This change only really covers C++ code using operator new/delete, and
not things that would be using malloc/free, because it's easier.
malloc/free is left for a followup.
Differential Revision: https://phabricator.services.mozilla.com/D32119
--HG--
extra : moz-landing-system : lando
We clear mGlassDisplayItem before a full display list build. We use it so that we only mark the first glass item we encounter with the glass item flag.
For partial builds we use the bool mHasGlassItemDuringPartial to track the same thing, so we only mark one item as glass. Merging handles updating mGlassDisplayItem for partial builds.
So this means that we could have one item marked as a glass item in the old list and one item marked as a glass item in the new list.
If merging doesn't use the existing mGlassDisplayItem then it clears mGlassDisplayItem. If merging uses a new item that is a glass item it calls SetGlassDisplayItem on it, so it will only become the new glass item if there wasn't one there already.
So it is actually possible that both items with the glass flag make it into the final display list. Thus the number of display items in the display list with the glass flag can grow to any number, but it would have to be a very very weird state because the glass item is only allowed to be a themed background item coming from a doc element box frame (one per xul doc near the root).
Differential Revision: https://phabricator.services.mozilla.com/D32558
--HG--
extra : moz-landing-system : lando
- DISABLE_SHARED_JS and DISABLE_EXPORT_JS have been deprecated for 3
years,
- MOZ_JEMALLOC4 has been deprecated for 2 years.
Differential Revision: https://phabricator.services.mozilla.com/D32928
--HG--
extra : moz-landing-system : lando
