This patch simply removes GTK_PRINT_CAPABILITY_PAGE_SET from our
GtkPrintCapabilities struct. This flag is documented as controlling whether
the gtk "Print dialog will offer printing even/odd pages", per
https://developer.gnome.org/gtk3/stable/GtkPrintUnixDialog.html
After this change, the "Only Print: All Sheets | Even Sheets | Odd Sheets"
dropdown-menu in the GTK Print Dialog will be grayed out & disabled, which will
accurately indicate that we don't support this feature.
Differential Revision: https://phabricator.services.mozilla.com/D92527
I created a new test file for testing markers in the parent process. It
can be re-used to test a variety of different markers and their payloads
to ensure they are properly being created, and with relevant information.
The idea here is that this tests the entire pipeline, and excercises the
code as an end user of the profiler would.
Differential Revision: https://phabricator.services.mozilla.com/D92457
This is part of the Markers 2.0 work. This payload proved to be a bit ambiguous
when moving to the new marker schema, so it requires an upgrader.
The test is included as the following commit.
Differential Revision: https://phabricator.services.mozilla.com/D92456
Because we special case the decoding code for element segments, the change
to use heap types for ref.null wasn't propagated from OpIter. We should
decode as a heap type here.
Differential Revision: https://phabricator.services.mozilla.com/D91997
ModuleEnvironment contains a CompilerEnvironment pointer, which describes the compiler selection,
tiering, and whether debugging is enabled. None of this information is needed for validation,
so wasm::Validate() has to create a synthetic CompilerEnvironment which is never read. This
isn't a large issue, but indicates ModuleEnvironment is doing too many things.
This commit removes CompilerEnvironment from ModuleEnvironment and pipes it
through the compiler pipeline. This is fairly straightforward except for:
* wasm::Validate() no longer needs to create a synthetic compiler env
* DecodeModuleEnvironment() used to invoke moduleEnv.compilerEnv.computeParameters(d)
after the preamble was decoded. I believe this was needed for handling the GC opt-in
section, which is no longer used. I moved this call to computeParameters() to after
all callers of DecodeModuleEnvironment().
* I added an assertion in IonCompileFunctions/CraneliftCompileFunctions that they are
not being invoked for debugged modules.
Differential Revision: https://phabricator.services.mozilla.com/D91995
The next commit will move CompilerEnvironment out of ModuleEnvironment and pass it
through the compiler pipeline. The compiler pipeline typically uses 'env_' to refer
to the module environment, with a 'compilerEnv_' being used as well I think we should
rename 'env_' to 'moduleEnv_'.
The one exception is within validation/decoding where I think using just 'env_' to
refer to the module environment is fine.
Differential Revision: https://phabricator.services.mozilla.com/D91994
The existing implementation of `@imports()` in the `configure` sandbox doesn't translate an import of the form `@imports('distutils.sysconfig')` into an `import distutils.sysconfig` statement; instead, it transforms the input `@imports()` request a few times in such a way that we eventually just do `import distutils`, and expect that `distutils.sysconfig` will be populated that way. This would be fine, except that this isn't the way that Python's `import` system works:
```
>>> import distutils
>>> distutils.sysconfig
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: module 'distutils' has no attribute 'sysconfig'
>>> import distutils.sysconfig
>>> distutils.sysconfig
<module 'distutils.sysconfig' from '/usr/lib/python3.8/distutils/sysconfig.py'>
```
i.e., we can't just import a parent module and expect that we can indirectly access all child packages of that module without importing them specifically.
So instead, we simplify the current model somewhat by not transforming the `@imports()` request at all and instead just performing the exact `import` that the user requested. This resolves the `distutils.sysconfig` issue as well as hopefully preventing any other similar issues popping up in the future.
While I'm here, I also refactored some stuff so that the way that we're patching in wrapped modules for the sandbox is more structured.
Differential Revision: https://phabricator.services.mozilla.com/D90627
Lack of support for specialPowers is often cited as a reason for
developers to write mochitests rather than wpt. Although using
specialPowers means that the tests can't be upstreamed, having it
available in gecko-only tests should reduce the need to write
mochitests and potentially means that a patch which previously would
be written with just mochitests would instead be written with just
wpt, a fraction of which would be unsuitable for sharing.
Nevertheless a gecko-only specialPowers-using test should be
considered the option of last resort when cross-browser APIs such as
testdriver aren't sufficient.
This patch installs the specialPowers extension when the path to the
XPI is provided via a --specialpowers-path command line argument. To
ensure this only happens for gecko-only tests, the url_base is added
to the Test object, and the firefox settings() method is updated to
contain a specialpowers setting, which uses the url_base of the test
to determine if this is a gecko-only test.
Because the extension has to be enabled using marionette, we also need
to route this setting through the to executor, along with the provided
XPI path.
Differential Revision: https://phabricator.services.mozilla.com/D92035
Previously invocations of `mach test` were broken with a weird error
message:
The underlying problem is a Python syntax error on line 0:
None
Removing the first line seems to fix that.
Now this is a Python file, so re-introducing the general mode line and a
vim line matches what others are doing too.
Differential Revision: https://phabricator.services.mozilla.com/D92560
Lack of support for specialPowers is often cited as a reason for
developers to write mochitests rather than wpt. Although using
specialPowers means that the tests can't be upstreamed, having it
available in gecko-only tests should reduce the need to write
mochitests and potentially means that a patch which previously would
be written with just mochitests would instead be written with just
wpt, a fraction of which would be unsuitable for sharing.
Nevertheless a gecko-only specialPowers-using test should be
considered the option of last resort when cross-browser APIs such as
testdriver aren't sufficient.
This patch installs the specialPowers extension when the path to the
XPI is provided via a --specialpowers-path command line argument. To
ensure this only happens for gecko-only tests, the url_base is added
to the Test object, and the firefox settings() method is updated to
contain a specialpowers setting, which uses the url_base of the test
to determine if this is a gecko-only test.
Because the extension has to be enabled using marionette, we also need
to route this setting through the to executor, along with the provided
XPI path.
Differential Revision: https://phabricator.services.mozilla.com/D92035
This patch enabled mitm5 for browsertime desktop tests. It also fixes a small issue in mozproxy which sets the return code to 0 on a failure.
Differential Revision: https://phabricator.services.mozilla.com/D92434
This gets rid of an ad-hoc boolean constant and introduces a configuration flag
for experimental SIMD instructions. The flag is on by default in Nightly if
SIMD is also enabled; otherwise off. This patch therefore disables support for
experimental SIMD instructions in beta and release, where they have been
available with the other SIMD instructions behind a pref. This seems OK:
code using unstable bits of an in-progress proposal should stick to Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D92554
When debugging text issue on GV, I sometimes enable `DEBUG_ANDROID_IME` to
output log. But I think that it is better to use `MOZ_LOG` since we can get
the log on Fenix build.
If using GVE, we can output log via the following command.
```
adb shell am start -n org.mozilla.geckoview_example/.GeckoViewActivity --es env0 "MOZ_LOG=GeckoEditableSupport:5"
```
But this change is Nightly only due to footprint etc at first.
Differential Revision: https://phabricator.services.mozilla.com/D92449
When ANGLE detects device reset, GetDeviceOfEGLDisplay() returns nullptr. It is not handled as device reset in current RenderCompositorANGLE::ShutdownEGLLibraryIfNecessary(). It should be handled as device reset.
Differential Revision: https://phabricator.services.mozilla.com/D92543
This is a speculative fix. Open to suggestions if there's a better approach.
## Context
When clicking a node in the Markup view, the `MarkupContainer` for that node will shift focus to the [first editor](https://searchfox.org/mozilla-central/rev/d54210d490ef335b13fc1fcac817525120c8c46b/devtools/client/inspector/markup/views/markup-container.js#777-786) for that node's attributes. This is good for accessibility and for keyboard navigation. But when the Markup view is narrow, the effect is shifting the horizontal scroll in order to bring the editor into view.
As a mouse user, if I want to double click a node attribute to edit it, the focus shifts as soon as I click first.
This is particularly annoying for attributes at the far end of the node. I can't edit the attribute because it shifts away as the focus moves to the first editor.
A workaround is to tab through the attribute editors until I get to the desired one
Video of the effect and workaround:
{F2424060}
## Proposed fix
The proposed fix is to keep the original behavior on first click on a `MarkupContainer` (focus the first editor, shift scroll if the viewport is too narrow).
But on second click, i.e. the `MarkupContainer` is already selected, skip moving focus and allow the user to edit node attributes.
Video of the effect with the patch applied
{F2424065}
Differential Revision: https://phabricator.services.mozilla.com/D87869
