They are equivalent, except for the fact that MACOSX_DEPLOYMENT_TARGET
may apply to more processes in a normal build. In practice, all the
processes that matter are covered through compiler flags.
On the opposite end, MACOSX_DEPLOYMENT_TARGET isn't necessary passed in
all cases (like clangd, mach static-analysis, etc.), while compiler
flags are.
Differential Revision: https://phabricator.services.mozilla.com/D122145
This hides the scProfilerMainThreadId detail, and makes for a safer API.
Also, ::profiler_init_main_thread_id() calls ::mozilla::baseprofiler::profiler_init_main_thread_id().
And in non-MOZ_GECKO_PROFILER builds, AUTO_PROFILER_INIT calls profiler_init_main_thread_id(), which makes other main-thread functions usable there (assuming profiler_current_thread_id works).
Differential Revision: https://phabricator.services.mozilla.com/D121695
This patch only shuffles source code around, so that all declarations in {,Base}ProfilerUtils.h are now implemented only in ProfilerUtils.cpp (instead of the different platform-*.cpp), the final generated code should be the same in MOZ_GECKO_PROFILER builds (the default on all our supported platforms).
This simplifies the headers and makes further changes easier.
In non-MOZ_GECKO_PROFILER builds: On supported platforms these functions are now fully defined; Unsupported platforms should all had `getpid()`, but thread ids are null.
So now `profiler_current_process_id()` is available on all platforms, at all tier levels.
Differential Revision: https://phabricator.services.mozilla.com/D121051
An upcoming patch will change the size of ProfilerThreadId, which causes troubles with TracePayload.
Trying to move members around didn't help, I'm guessing some padding remains, which cannot be accounted for by just enumerating member sizes.
The proposed solution is to wrap all members in a macro (so they don't need to be repeated), and create a private struct with these members and a character, in order to find the exact offset at which the name will actually start.
This is uglier, but more flexible, and allows future changes (internal or external) more easily, without having to modify the name-size formula.
Differential Revision: https://phabricator.services.mozilla.com/D121050
Since ProfilerProcessId and ProfilerThreadId (and their NumberTypes) will potentially grow to 64 bits on some platforms (in a later patch), all code that uses them must be able to handle bigger types.
Differential Revision: https://phabricator.services.mozilla.com/D121049
It tries to replace a following NBSP with an ASCII white-space if there is.
However, it calls the scan method with start of the replacing range. Therefore,
the assertion in `GetInclusiveNextNBSPPointIfNeedToReplaceWithASCIIWhiteSpace()`
detects this bug.
Note that this occurs only when updating composition string because it's
called with non-collapsed range only for doing it. Otherwise, selected range
has already been deleted by `HTMLEditor::DeleteSelectionAsSubAction()`.
Unfortunately, I don't have how to make this bug appear. It seems that the
path does nothing in the wild because it tries to replace a first character
of composition string from an NBSP to a normal white-space, but it'll be
replaced with new composition string anyway. Therefore, this patch does not
have new tests.
Differential Revision: https://phabricator.services.mozilla.com/D122182
In an incremental reflow, if a flex item has a valid bsize cache , we
skip its measuring reflow. However, we may still need to set relevant
bsize flags if the flex container is changing its definiteness in the
block-axis. See bug 1611303 comment 2 for an analysis.
This patch is playing safe by always calling SetHasBSizeChange() if we
override bsize for the item. Of course this can be solved in a more
sophisticated way by checking whether the item really has a block-axis
resize, but that means we'll need to duplicate a lot of logic in
FlexItem::NeedsFinalReflow().
Differential Revision: https://phabricator.services.mozilla.com/D122041
As this means stdc++compat also would need to be built when
cross-building for Windows on Linux, we also recurse in the stdc++compat
directory in that case. It was already possible to use
--enable-stdcxx-compat in that configuration, and that wasn't working
(there are other problems that prevent it from working, but we're going
to fix them shortly).
Differential Revision: https://phabricator.services.mozilla.com/D122195
Since the minimum required version of gcc and libstdc++ is 7.1 as of bug
1536848, the _GLIBCXX_RELEASE macro is available on all supported
versions. Which means instead of grabbing the largest version of the
libstdc++ symbols and tweaking for that, we can just tweak for
_GLIBCXX_RELEASE. We also remove the conditions that are always true due
to the versions involved.
Differential Revision: https://phabricator.services.mozilla.com/D122194
This patch implements device-pixel-content-box for ResizeObserver.
GetTargetSize() returns CSS pixels for {border|content}-box, or device
pixels for device-pixel-content-box. We round the device pixel to
integral based on the spec,
https://drafts.csswg.org/resize-observer/#calculate-box-size.
And then we compare the current calculated box sizes and the last updated one
in IsActive().
Besides, the current wpts only use zoom property to verify this, but zoom
property is non-standard and we doesn't supports it, so now we only test the
getter functions for device-pixel-content-box and the subpixel snapping
algorithm (e.g. devicepixel.html) for Gecko in wpts.
Differential Revision: https://phabricator.services.mozilla.com/D120776
LogicalPixelSize is a variant of LogicalSize but it stores pixel values
in floating-point. Now we store LogicalPixelSize in ResizeObservation and
ResizeObserverSize. This makes us easier to introduce device-pixel-content-box.
Differential Revision: https://phabricator.services.mozilla.com/D121155
We will introduce device-pixel-content-box, which is in device-pixel
domain. Therefore, we convert the app units into CSS/device pixel when creating
ResizeObserverSize.
Differential Revision: https://phabricator.services.mozilla.com/D121016
Font inflation isn't required for pages whose viewport is narrow enough that we
don't have to zoom *out* when doing zoom-to-fit.
As the viewport scale is given as a CSSToScreenScale, this means that what we're
actually doing at the moment, though, is comparing the width of the viewport in
CSS pixels to the width of the screen in physical pixels, *without* taking the
default scale on a high-DPI device into account.
This issue affects neither pages using a "width=device-width" viewport (the
IsAutoSizeEnabled() check handles those), nor pages without an explicitly
specified viewport at all (the viewport info returns the minimum zoom level in
that case, i.e. 25 %, which would therefore require a device scale of > 4 in
order for us to erroneously turn off font inflation - even modern phones don't
seem to quite reach *that* sort of pixel density, e.g. a Pixel 5 only reports a
default scale of ~2.73.
For pages with an explicitly sized viewport this can however mean that we turn
off font inflation too early: Slashdot e.g. uses "width=1000", which means that
on a phone with a 720 px screen font inflation is correctly enabled, but on a
different phone squeezing 1080 px into the same physical screen width (i.e.
higher DPI, but *not* a physically larger screen), font inflation is suddenly
and incorrectly turned off.
Differential Revision: https://phabricator.services.mozilla.com/D122059
Touching layout.css.devPixelsPerPx during a reftest seems to cause a few
peculiarities:
- On OS X, increasing layout.css.devPixelsPerPx almost immediately runs into
bug 1263092, so I'm skipping that test there.
- Likewise, under Webrender on Android using a value > 1 causes some weird
display corruption issues during all subsequent tests running within the same
task (bug 1724608).
- We're randomly hitting the "can't mark frame dirty during reflow" assertion
again (bug 1724623).
Differential Revision: https://phabricator.services.mozilla.com/D122058
For pages with an explicitly sized viewport, whether or not we enable font
inflation depends on whether the viewport is larger than content viewer size (so
it will be displayed zoomed out) or not.
For historical reasons, so far we've used the screen size as a proxy for the
content viewer size. On a phone this is a reasonable approximation (albeit a bit
less so now that Android also offers split-screen and picture-in-picture modes),
but when testing/debugging on a desktop computer, this means that the results
will depend on the screen size of the machine in question, which makes it rather
hard writing sensible test cases for that scenario.
Therefore, we're finally following up with that TODO comment in the existing
code and start using the content viewer size of the top-level document instead.
Fission means that approach won't easily work for cross-process iframes, but
given that the current calculations don't make much sense for frames anyway, we
just accept that limitation, since a proper solution as per bug 1724311 would
obsolete any work done here anyway.
Differential Revision: https://phabricator.services.mozilla.com/D122057
