Invert screen pixels in `nsWindow`.
Update `RequestScreenPixels` in `nsWindow` to accept a `GeckoResult` as an argument and save as a `GlobalRef`.
Update `RecvScreenPixels` in `nsWindow` in order to invert the image before sending over JNI rather than requiring callers to invert the image themselves.
Complete the `GeckoResult` if there is one in `RecvScreenPixels` instead of making a callback to the compositor.
Remove `RecvScreenPixels` from `GeckoSession` and `GeckoSession.Compositor`.
Move `RecvScreenPixels` and `getPixels` to `GeckoDisplay`
Rename `getPixels` to `capturePixels`
Return Bitmap from `RecvScreenPixels`.
Return `GeckoResult` from `capturePixels`.
Add doc comments to new methods and classes.
Update FennecNativeDriver to use `GeckoView` and `GeckoResult`.
Update API docs and Changelog
Add tests
Differential Revision: https://phabricator.services.mozilla.com/D18944
--HG--
extra : moz-landing-system : lando
- Detect current desktop session and disable shape mask on Mutter/X.org due to Bug 1530252 (mutter bug).
- Use system titlebar on Mutter/X.org as we can't draw the titlebar reliably.
- Remove widget.default-hidden-titlebar from prefs. When it's defined it overrides default titlebar detection heuristics now.
- Don't use shape masks at all on Mutter/x.org. When system titlebar is hidden in this case (by user choice) it has opaque corners unless
argb visual is selected.
- Use Window manager decorations on Gnome Classic session, that works better than client decorations.
Differential Revision: https://phabricator.services.mozilla.com/D21203
--HG--
extra : moz-landing-system : lando
By this change, icons will never be shrunk to a smaller size. Windows will do
it appropriately.
Internet Explorer's icon handler will not paint the white background if the
icon is large enough. I'm also replicating the behavior.
--HG--
extra : source : 56eb23aaff3a5a0dbca8e41c534307c30e7351f4
Bug 1514156 expects that nsWindow::OnExposeEvent() is called after frame_callback_handler() called. But it did not happen during opening add-ons(gecko profiler). Then we need to trigger rendering directly from frame_callback_handler() call.
Differential Revision: https://phabricator.services.mozilla.com/D20272
--HG--
extra : moz-landing-system : lando
This patch introduces a new module in widget that implements a simple API to
retrieve system information about a process and its threads.
This function is wrapped into ChromeUtils.RequestProcInfo to return information
about processes started by Firefox.
The use case for this API is to monitor Firefox resources usage in projects
like the battery usage done by the data science team.
Differential Revision: https://phabricator.services.mozilla.com/D10069
--HG--
extra : moz-landing-system : lando
This patch introduces a new module in widget that implements a simple API to
retrieve system information about a process and its threads.
This function is wrapped into ChromeUtils.RequestProcInfo to return information
about processes started by Firefox.
The use case for this API is to monitor Firefox resources usage in projects
like the battery usage done by the data science team.
Differential Revision: https://phabricator.services.mozilla.com/D10069
--HG--
extra : moz-landing-system : lando
`TextInputHandler::HandleCommand()` dispatches `Tab` key events only when
it receives `insertTab:` or `intertBacktab:` command which are caused by
actual `Tab` key press.
However, these commands could be generated by IME or the system shortcut
keys are customized oddly.
This patch makes the method support such situation with dispatching fake
`keydown` and `keypress` events to emulate `Tab` key press for
mainly focus navigation.
Differential Revision: https://phabricator.services.mozilla.com/D20804
--HG--
extra : moz-landing-system : lando
Currently, when IME sends a command with committing composition,
TextInputHandler::HandleCommand() dispatches a *fake* `keypress` event
for making default event handler (e.g., focused editor) handle the
event. However, we stopped dispatching `keypress` events for
non-printable keys. Therefore, web apps cannot do that like us.
On macOS, simple conversion IMEs like Korean 2-set IME, behave
differently if active application is changed. E.g., on Safari,
some of them may never use composition string, but not so on
Chrome and Firefox. So, this is what the case we need to emulate
Safari's behavior.
Dispatching a fake `keydown` event for this purpose does **not**
conform to UI Events because `keydown` events should notify web
apps of **physical** key state changes. However, Chrome dispatches
fake `keydown` events intentionally. Therefore, we should follow
this hacky behavior for user experience.
Differential Revision: https://phabricator.services.mozilla.com/D20644
--HG--
extra : moz-landing-system : lando
We didn't dispatch keyboard events during composition. Therefore, we tried to
retrieve raw virtual keycode value when key messages come with `VK_PROCESS`
unexpectedly. However, the API, `ImmGetVirtualKey()`, is not usable for this
purpose because it always returns `VK_PROCESS` if the key messages have already
been handled by IME. So, we can just stop using it since we need to expose
such key messages as KeyboardEvent whose `key` value is `Process` and `keyCode`
value is `DOM_VK_PROCESS`.
Differential Revision: https://phabricator.services.mozilla.com/D20623
--HG--
extra : moz-landing-system : lando
There seem to be a number of problems with Direct2D on the Qualcomm
devices. This includes visual corruption from bug 1515823 and crashes
in CHwRasterizer::RasterizeEdges from 1515387.
Using this flag will cause GeckoWebExecutor.fetch() to not automatically
follow redirects, which is the default behavior if no flag is specified.
Differential Revision: https://phabricator.services.mozilla.com/D19523
--HG--
extra : moz-landing-system : lando
Previously we were using NS_GetLuminosity which asserts for non-opaque colors,
and my system theme happens to use a background color with alpha=0.999.
Luminosity judgements do get a bit more hand-wavy as colors get more
transparent, but it seems like we can still reasonably make an overall
"dark theme" judgement based on the RGB channels.
Differential Revision: https://phabricator.services.mozilla.com/D20748
--HG--
extra : moz-landing-system : lando
This patch enables the shape mask in CSD and Window manager decorations mode
when we're runnin on composited screen and mozilla.widget.use-argb-visuals is not set.
Also don't use shape mask with Wayland and GL backend. When shape mask is set,
advertise toplevel window transparency but don't advertise it
as alpha to GtkCompositorWidget.
Differential Revision: https://phabricator.services.mozilla.com/D20726
--HG--
extra : moz-landing-system : lando
Remoting to a different user isn't supported everywhere and being able to
remote to a different application entirely is kind of odd. I don't think it
makes sense to continue to support these operations.
Differential Revision: https://phabricator.services.mozilla.com/D19066
--HG--
extra : source : b4210f85c7e9c86ef0f173b5d2250c2862fec992
extra : intermediate-source : 35287afd3acea1602bed159dc879aa666e64b9c8
Remoting to a different user isn't supported everywhere and being able to
remote to a different application entirely is kind of odd. I don't think it
makes sense to continue to support these operations.
Differential Revision: https://phabricator.services.mozilla.com/D19066
--HG--
extra : rebase_source : df03e6d2233c4235308f2f8c8ec860e8827254e5
extra : source : b4210f85c7e9c86ef0f173b5d2250c2862fec992
nsSystemInfo is initialzied at first page load. Actually, content process uses
sync IPC to get Android OS information. But now, we can use Java code even if
on content process, so we should use JNI directly instead of sync IPC.
Also, nsSystemInfo still has unused extern android_sdk_version that is for
HoneyComp's DNS hack. So let's remote it.
Differential Revision: https://phabricator.services.mozilla.com/D20129
--HG--
extra : moz-landing-system : lando
Splitting part of OGLShaderProgram.h out into OGLShaderConfig.h makes it
easier to keep GLContext.h included in OGLShaderProgram.h for inlining
purposes.
Differential Revision: https://phabricator.services.mozilla.com/D20017
--HG--
extra : moz-landing-system : lando
InputEvent.dataTransfer should be set to non-null when InputEvent.inputType
is "insertFromPaste", "insertFromDrop" or "insertReplacementText" and
editor is an HTMLEditor instance:
https://rawgit.com/w3c/input-events/v1/index.html#dfn-datahttps://w3c.github.io/input-events/#dfn-data
("insertTranspose" and "insertFromYank" are not currently supported on Gecko.)
This patch makes nsContentUtils::DispatchInputEvent() take dataTransfer value
and EditorBase set it via AutoEditActionDataSetter like data value.
However, we need to create other constructors of DataTransfer to create its
read-only instances initialized with nsITransferable or nsAString. This will
be implemented by the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D19297
--HG--
extra : moz-landing-system : lando
InputEvent.dataTransfer is declared by Input Events Level 1 and Level 2 (i.e.,
not UI Events). It's necessary for "beforeinput" event on contenteditable
elements because of with some InputEvent.inputType values on contenteditable,
InputEvent.dataTransfer is used instead of InputEvent.data.
According to the Chrome's behavior, if InputEvent.dataTransfer is created by
web apps, the DataTransfer object is mutable. Otherwise, i.e., the event
represents user input, the DataTransfer object is read only. We should follow
this behavior.
This is enabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D19296
--HG--
extra : moz-landing-system : lando
Although neither Chrome nor Safari does not set InputEvent.data when the event
is caused by `document.execCommand()` with `backColor`, `foreColor` nor
`hiliteColor`, Safari supports styling color with touchbar and in that case,
Safari sets it (*1).
Additionally, currently Safari uses `rgb()` to represents a color value and
using same rule to serializing color value for CSS OM matches Safari's behavior
and can represent any valid color values.
This patch makes given color value parsed and then serialized with same code
in style system. If the value is `currentcolor`, `inherit`, `initial` or `reset`, sets
the value as-is for now. Additionally, when given value is invalid, sets the value
as-is for forward compatibility.
Note that automated tests will be added into input-events-exec-command.html
by the last patch.
1. https://github.com/w3c/input-events/issues/94#issuecomment-461061517
Differential Revision: https://phabricator.services.mozilla.com/D19295
--HG--
extra : moz-landing-system : lando
Although neither Chrome nor Safari does not set InputEvent.data value when
InputEvent.inputType is "fontName", but it's easy to implement. Therefore, this
patch implements it as declaration of Input Events.
This patch uses given value as-is. Perhaps, this shouldn't cause any problems
because such value can be set to Element.style.fontFamily without any changes.
Note that automated test will be added into WPT later.
Differential Revision: https://phabricator.services.mozilla.com/D19294
--HG--
extra : moz-landing-system : lando
Although neither Chrome nor Safari does not set InputEvent.data value when
InputEvent.inputType is "insertLink", but it's easy to implement. Therefore,
this patch implements it as declaration of Input Events.
This patch sets the value to raw href attribute value because we create
<a> element without absolute URI when web apps call execCommand("createLink")
with relative URI.
Differential Revision: https://phabricator.services.mozilla.com/D19291
--HG--
extra : moz-landing-system : lando
When InputEvent.inputType is "formatSetBlockTextDirection" or
"formatSetInlineTextDirection", InputEvent.data value should be one of
"ltr", "rtl", "auto" or "null".
https://rawgit.com/w3c/input-events/v1/index.html#dfn-datahttps://w3c.github.io/input-events/#dfn-data
We only supports "ltr" and "rtl" when user switches the direction with
Accel + Shift + X. Therefore this patch makes EditorBase set the data
to "ltr" or "rtl".
Oddly, with synthesizing the shortcut keys, the command is not executed
properly in the automated test. Therefore, this patch dispatches the
command directly.
Differential Revision: https://phabricator.services.mozilla.com/D19288
--HG--
extra : moz-landing-system : lando
https://rawgit.com/w3c/input-events/v1/index.html#dfn-datahttps://w3c.github.io/input-events/#dfn-data
Both Input Events Level 1 and Level 2 declare that InputEvent.data should be
set to inserting string only on TextEditor when InputEvent.inputType is
"insertFromPaste", "insertFromPasteAsQuotation", "insertFromDrop",
"insertTranspose", "insertReplacementText" or "insertFromYank".
Currently, we support only "insertFromPaste", "insertFromDrop",
"insertReplacementText". Therefore, this patch makes TextEditor set
EditorBase::mEditActionData::mData only for them (and the instance is not
HTMLEditor's).
Differential Revision: https://phabricator.services.mozilla.com/D19287
--HG--
extra : moz-landing-system : lando
InputEvent.data notifies web apps of inserting/inserted text with "beforeinput"
and "input" events. So, this is important especially for "beforeinput" event
listeners. That's the reason why we need to support this before implementing
"beforeinput" event.
This patch adds it into InputEvent and make it enabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D19285
--HG--
extra : moz-landing-system : lando
nsWaylandDisplay needs to be allocated for each calling thread(main thread, compositor thread and render thread)
Differential Revision: https://phabricator.services.mozilla.com/D20118
--HG--
extra : moz-landing-system : lando
widget/cocoa/nsChildView.mm:249:6 [-Wmissing-prototypes] no previous prototype for function 'EnsureLogInitialized'
Depends on D20087
Differential Revision: https://phabricator.services.mozilla.com/D20088
--HG--
extra : moz-landing-system : lando
widget/cocoa/nsChildView.mm:1932:21 [-Wmissing-prototypes] no previous prototype for function 'TextureSizeForSize'
widget/cocoa/nsCocoaUtils.mm:351:6 [-Wmissing-prototypes] no previous prototype for function 'data_ss_release_callback'
Differential Revision: https://phabricator.services.mozilla.com/D20087
--HG--
extra : moz-landing-system : lando
In order to get the alpha channel when encoding BMP images from a
surface, we need to supply bmp=32 in the encoder options.
Differential Revision: https://phabricator.services.mozilla.com/D19835
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
The only caller wants CSS pixels, no need to go back and forth.
This is the last dependency on the pres context, I think, from the style system
font code.
Differential Revision: https://phabricator.services.mozilla.com/D19147
This is a clearer implementation that achieves the same thing.
Moreover, disabling the clearing by overriding drawRect wouldn't work in
CoreAnimation windows because in CoreAnimation windows, the clearing happens
through a property of the NSVisualEffectView's CALayer, and not through the
view's drawRect implementation - drawRect probably isn't even called in that
context.
Differential Revision: https://phabricator.services.mozilla.com/D19601
--HG--
extra : moz-landing-system : lando
This has two advantages:
- The drawing will now correctly be placed "on top" of the vibrancy views.
- We can turn this new view into a layer-hosting view. Layer-hosting views are
supposed to be leaf NSViews; they shouldn't have any children.
Differential Revision: https://phabricator.services.mozilla.com/D19600
--HG--
extra : moz-landing-system : lando
Otherwise, any views inside the contentView are imbued with a vibrant effect, and
even non-NSVisualEffectView NSViews subtract from the vibrant region of any actual
vibrant views they overlap. This would cause the PixelHostingView to 'erase' the
blue context menu item highlighting.
This behavior is documented on NSVisualEffectView:
> It is recommended that you enable vibrancy only in the leaf views of your view
> hierarchy. Subviews inherit the vibrancy of their parent. Once enabled in a
> parent view, a subview cannot turn off vibrancy. As a result, enabling
> vibrancy in a parent view can lead to subviews that look incorrect if they are
> not designed to take advantage of the vibrancy effect.
Differential Revision: https://phabricator.services.mozilla.com/D19599
--HG--
extra : moz-landing-system : lando
NSView hierarchy before:
- window contentView
- ChildView
- NonDraggableView 1
- NonDraggableView 2
- EffectViewWithoutForegroundVibrancy 1
- EffectViewWithoutForegroundVibrancy 2
NSView hierarchy after:
- window contentView
- ChildView
- ViewRegionContainerView
- NonDraggableView 1
- NonDraggableView 2
- ViewRegionContainerView
- EffectViewWithoutForegroundVibrancy 1
- EffectViewWithoutForegroundVibrancy 2
This allows us to give those container views a new sibling view which stays
fixed in z-order with respect to the NSViews that get created by
mNonDraggableRegion and mVibrancyManager. More specifically, I'm going to add a
view for the drawing of our ChildView ("PixelHostingView") which is going to be
a direct child of the Gecko "ChildView" and a sibling of the
ViewRegionContainerViews; the PixelHostingView needs to always stay on top of
the vibrancy views.
Without the wrapper around the vibrancy views, whenever the vibrant region
changes, a vibrant view would be placed on top of the PixelHostingView and the
order would be wrong.
Differential Revision: https://phabricator.services.mozilla.com/D19598
--HG--
extra : moz-landing-system : lando
This was added in bug 476393 in order to work around a problem with the Java plug-in.
We no longer support that plug-in.
The comment also mentions NSTexturedBackgroundWindowMask which we stopped using in bug 1335191.
Differential Revision: https://phabricator.services.mozilla.com/D19558
--HG--
extra : moz-landing-system : lando
This method could only return something non-null in embedding situations,
in which our ChildView was a subview of somebody else's NSView that conforms
to the mozView protocol. Such a situation hasn't existed for about 10 years.
Differential Revision: https://phabricator.services.mozilla.com/D19555
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
When GDK_BACKEND is wayland, widget is not fully mapped during creating CompositorSession. Needs to create valid EGLSurface after widget is fully mapped.
Differential Revision: https://phabricator.services.mozilla.com/D18940
Chromium does workaround for scrolling with touch and avoid bitmap allocation when child window is used for DirectComposition. It improves performance of WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D18659
During security.sandbox.gpu.level=1, compositor window's parent cannot be set in GPU process, it needs to be set in UI process.
Differential Revision: https://phabricator.services.mozilla.com/D18811
Recently we quit nsWindow::OnWindowStateEvent()/window_state_event handler when titlebar needs an update due to focus change.
That's incorrect as we need to process other information from the handler - maxminized/normal window state.
Differential Revision: https://phabricator.services.mozilla.com/D18681
--HG--
extra : moz-landing-system : lando
Unfortunately, we're not sure whether ibus always handles non-dead key events
asynchronously or synchoronously. Therefore, for safer fix, this patch makes
IMContextWrapper::OnKeyEvent() decide that with the result of
gtk_im_context_filter_keypress(). If active IME is ibus and it consumes non-
synthesized events on password fields, it adjusts probablyHandledAsynchronously
value.
So, this patch changes the behavior of only when:
- active IME is ibus.
- only when a password field or ime-mode:disabled field has focus.
- not in dead key sequence.
- and the key event is consumed by ibus but nothing happend.
This must be enough safe to uplift.
Differential Revision: https://phabricator.services.mozilla.com/D18635
--HG--
extra : moz-landing-system : lando
Now, we believe that when `maybeHandledAsynchronously` is set to true,
ibus handles the event asynchronously in usual cases. However, the behavior
of ibus on password field is unclear. Currently, on Ubuntu 18.04,
Ubuntu 18.10 and Debian Cinnamon (9.6 / 3.2.7), ibus handles key events
asynchronously even in password fields even though I confirmed it was not
so at initial fix. So, it could be just my mistake, but we need to prepare
for both cases here for safer fix.
So, in the following patch, I need to add another variable for weaker
decision, and we treat `maybeHandledAsynchronously` stronger than its
nuance. Therefore, this patch renames it to `probablyHandledAsynchronously`.
Differential Revision: https://phabricator.services.mozilla.com/D18634
--HG--
extra : moz-landing-system : lando
Casting non-void result to `void*` causes warning of clang. Additionally,
perhaps, we should use `Unused <<` because of modern style.
And also this patch makes widget/windows is treated as "warning as errors"
because this patch fixes the last warning.
Differential Revision: https://phabricator.services.mozilla.com/D17216
--HG--
extra : moz-landing-system : lando
So that we can query the test value in the child process properly.
Note that the APIs used for setting the prefers-reduced-motion value for testing
are only used on Android and MacOSX. As for MacOSX we have a different
machinery (see bug 1486971) to deliver the test value without spinning native
event loop in the child process so the change here is valid only for Android.
Differential Revision: https://phabricator.services.mozilla.com/D18311
--HG--
extra : moz-landing-system : lando
When hardware acceleration is enabled, GLContextGLX::FindVisual() is used to choose visual. When widget does not request AlphaVisual, the FindVisual() always choose RGB(24bit) visual. It causes to loose alpha during readback.
Differential Revision: https://phabricator.services.mozilla.com/D18179
--HG--
extra : moz-landing-system : lando
We currently use ParentLayer pixels in GestureEventListener, it should
be Screen pixels because we care about physical distances and
thresholds, not layer-relative ones.
Differential Revision: https://phabricator.services.mozilla.com/D17042
--HG--
extra : moz-landing-system : lando
This stops the use of some win32k calls during start-up that will fail and in
some cases cause a crash.
It also moves the MITIGATION_DYNAMIC_CODE_DISABLE to be enabled after start-up.
This is required because the hooks to fake the user32 and gdi32 initialization
are applied as the DLLs load and the dynamic code disable blocks that.
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
This cleans up a bit and allows us to be smarter about which cursors
should we allow from content or what not, which will help with bug 1445844 and
co.
Differential Revision: https://phabricator.services.mozilla.com/D16711
DisplaySystemMenu() does not handle nsSizeMode_Invalid that causes warning of
clang. This patch makes it treat nsSizeMode_Invalid. When it receives the
value, it will call NS_ASSERTION() to be detectable on debug builds during
automated tests.
Additionally, this adds default case into the switch statement with
MOZ_ASSERT_UNREACHABLE(). Then, when somebody adds new nsSizeMode, they
can detect it with crash in debug build if they forget to change this method.
Differential Revision: https://phabricator.services.mozilla.com/D17217
--HG--
extra : moz-landing-system : lando
The method was added by bug 506926, but not sure when this becomes an orphan.
Differential Revision: https://phabricator.services.mozilla.com/D17215
--HG--
extra : moz-landing-system : lando
Use only ':' separator instead of 'menu:' to place titlebar buttons as the menu may not be always present.
Differential Revision: https://phabricator.services.mozilla.com/D17480
--HG--
extra : moz-landing-system : lando
To support rounded corners of Gtk+ titlebar themes (Adwaita, Radiance..) in GNOME we need to use X shape mask
as fully transparent toplevel window causes various issues (like Bug 1516224).
We draw mShell as transparent and mContainer as non-transparent with shape mask applied. The shape mask
is generated only when titlebar rendering is enabled and it's generated from GtkHeaderBar Widget
to match the exact look.
We use existing mTransparencyBitmap for the shape mask where mTransparencyBitmapForTitlebar controls
whether it's a general shape mask or our specialised shape for titlebar only.
This is already enabled for GNOME environment by default. So there's a new preference
widget.default-hidden-titlebar added to easily disable it if any issue appears
during testing.
Differential Revision: https://phabricator.services.mozilla.com/D17283
--HG--
extra : moz-landing-system : lando
nsDataObj::GetDib() calls GetLastError() API immediately after calling
GlobalAlloc() and just return E_FAIL in such case. So, we don't need to
call it.
Differential Revision: https://phabricator.services.mozilla.com/D17214
--HG--
extra : moz-landing-system : lando
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
