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
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
gfxUtils::EncodeSourceSurface no longer uses a stringly-typed API to create a
`imgIEncoder` for the relevant MIME type. Instead, we now use an enum class and
switch on it to create the encoder.
Depends on D14816
Differential Revision: https://phabricator.services.mozilla.com/D14817
--HG--
extra : moz-landing-system : lando
Native toast notification uses WinUtils::WriteBitmap to bitmap for notification now. Since it uses old BITMAPINFOHEADER structure, it doesn't support alpha.
So I would like to support alpha value to WinUtils::WriteBitmap.
Differential Revision: https://phabricator.services.mozilla.com/D14670
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
A wrapper for ::GetModuleFileNameW() is needed in multiple places for the
purpose of evaluating and processing untrusted DLLs. This adds the appropriate
wrapper to WinUtils.cpp
Depends on D6240
Differential Revision: https://phabricator.services.mozilla.com/D9163
--HG--
extra : moz-landing-system : lando
Bug 1435827 part 3/9: Add WinUtils::PreparePathForTelemetry;r=aklotz
PreparePathForTelemetry encapsulates our method of removing sensitive
information from file paths for use in telemetry payloads.
SanitizePath() has been essentially renamed to PreparePathForTelemetry()
which is a bit more precise now that it's being used externally.
Untrusted modules evaluation requires a few path transformations to happen at
various places during processing. This is largely because APIs like
GetLongPathNameW can be rather slow, so performance becomes an issue.
That is the justification for breaking out path transformations into separate
wrapper functions and also the need for PathFlags.
Differential Revision: https://phabricator.services.mozilla.com/D6240
--HG--
extra : moz-landing-system : lando
Unfortunately there is no realiable way to tell whether there is no mouse
connected or not. So we are going to take a heuristic way here. The way is
that;
1) Count mouse type devices with SetupDiEnumDeviceInterfaces [1]
2) If the count is 1 and if the system is used as tablet or has a touch device,
the device should be COARSE
This way causes a misrecognition as if there is a mouse device in the case
where the touchscreen is disabled on the tablet even if there is no mouse
connected (i.e. the case where CountMouseDevices() returns 1 and the system
is on table mode). We will try to fix the misrecognition in a later bug
(bug 1495938).
[1] https://docs.microsoft.com/en-us/windows/desktop/api/setupapi/nf-setupapi-setupdienumdeviceinterfaces
Differential Revision: https://phabricator.services.mozilla.com/D7565
--HG--
extra : moz-landing-system : lando
Unfortunately there is no realiable way to tell whether there is no mouse
connected or not. So we are going to take a heuristic way here. The way is
that;
1) Count mouse type devices with SetupDiEnumDeviceInterfaces [1]
2) If the count is 1 and if the system is used as tablet or has a touch device,
the device should be COARSE
This way causes a misrecognition as if there is a mouse device in the case
where the touchscreen is disabled on the tablet even if there is no mouse
connected (i.e. the case where CountMouseDevices() returns 1 and the system
is on table mode). We will try to fix the misrecognition in a later bug
(bug 1495938).
[1] https://docs.microsoft.com/en-us/windows/desktop/api/setupapi/nf-setupapi-setupdienumdeviceinterfaces
Differential Revision: https://phabricator.services.mozilla.com/D7565
--HG--
extra : moz-landing-system : lando
WriteBitmap will be used for Toast implementation, so it should be moved to
WinUtils.
Differential Revision: https://phabricator.services.mozilla.com/D3002
--HG--
extra : rebase_source : b418288b52e14f62122f56dbc40e771c73fd6414
WriteBitmap will be used for Toast implementation, so it should be moved to
WinUtils.
Differential Revision: https://phabricator.services.mozilla.com/D3002
--HG--
extra : rebase_source : 7ec7593fd0294dcaa6aab5e8f503b5aa752cb9d1
We're already committing jump lists on mIOThread, and I see
no errors or problems with initting on mIOThread either, so
I think this is okay. Had to restructure some things to
make using a Promise simple, and to avoid dispatching to
mIOThread from within mIOThread (since we can only dispatch
to a LazyIdleThread from the owner thread).
MozReview-Commit-ID: 1imBF8Jzmn6
--HG--
extra : rebase_source : 4f912e819cec898910e72d95311e3924714a3090
By the proposal from Google, <https://github.com/w3c/uievents/issues/147>,
Chromium treat AltRight key as "AltGraph" modifier if the keyboard layout
has AltGr key.
When AltRight key is pressed with a keyboard layout which has AltGr key,
modifiers should as following:
1. "keydown" for ControlLeft:
ctrlKey: true, altKey: false, getModifierState("AltGraph"): false
2. "keydown" for AltRight:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): true
3. Some "keydown", "keypress" and "keyup" events:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): true
4. "keyup" for ControlLeft:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): true
5. "keyup" for AltRight:
ctrlKey: false, altKey: false, getModifierState("AltGraph"): false
So, only when the preceding "keydown" event for ControlLeft, ctrlKey should
be set to true as usual. However, after AltRight key is pressed actually,
we should treat "AltGraph" modifier is true and both ctrlKey and altKey
should be set to false for web apps can handle text input normally.
So, MODIFIER_ALTGRAPH and MODIFIER_CONTROL/MODIFIER_ALT should not be set
at the same time.
This patch makes ModifierKeyState have only MODIFIER_ALTGRAPH or
MODIFIER_CONTROL/MODIFIER_ALT.
Additionally, this patch makes VirtualKey::ShiftState treat "AltGraph" as a
modifier. So, now, VirtualKey needs to convert ShiftState to index value when
it accesses its mShiftStates array. Therefore, this patch adds
VirtualKey::ToIndex() and make each VirtualKey method use it before
accessing mShiftStates.
Note that this patch also fixes bug of WinUtils::SetupKeyModifiersSequence().
The constructor of KeyPair takes 2 keycode values, but the second virtual
keycode can have scancode to distinguish if the key is left or right.
However, WinUtils::SetupKeyModifiersSequence() never sets scancode to
KeyPair. Therefore, it fails to dispatch AltRight key event.
MozReview-Commit-ID: 7ealxJH9KlZ
--HG--
extra : rebase_source : 761bc4416222def020a0731d6ae7940ef074ebe0
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : dd000a05bfc2da40c586644d33ca4508fa5330f6
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : 59e4a6ced7d14d2a01c0b79e944078ea84cae523
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : a8840bd26f4b01b756ffa72345ababb625048550
Mostly just convert nsInt{Rect,Region} to LayoutDeviceInt{Rect,Region}.
One exception is to change the parameter of nsWindow::OnResize from
nsIntRect to LayoutDeviceIntSize, because it really only needs that.
MozReview-Commit-ID: 963Mzd5Wed6
--HG--
extra : rebase_source : efae039d26feb98a3591a7cd46c30ce4f052d70b
Bug 1354020 causes that IMM-IME on Windows 7 doesn't work with --no-remote. Although I think that this issue is OS or IME bug, when default window proceduce by RegisterClass is DefaultWindowProcW, Google Japanese IME doesn't work.
I am not sure why this issue occurs when lpfnWndProc is DefWidnowProcW and DDE isn't started. But for workaround, we should revert a part of bug 1354020 changes.
MozReview-Commit-ID: BkxlZnm8mIh
--HG--
extra : rebase_source : 21c1d86fb5628dbd726a15e5057a536271cfb26d
When removing our Windows message loop pumping code in the content
process, a11y code on the MTA thread must have some way to wake up the
main thread. The main thread could be blocked either on a conditional
variable waiting for a Gecko event, or it could be blocked waiting on
a Windows HANDLE in IPC code (doing a sync message send). In the
former case, we wake it up by posting an event to the main thread. In
the latter case, we continue to use the asynchronous procedure call
mechanism.
MozReview-Commit-ID: FN6KWaGo9Zl
This patch also adds logging into ResolveJunctionPointsAndSymLinks to help diagnose issues that
might arise if the resolution fails or the path is not usable for some reason.
Ryan Hunt
Masatoshi Kimura
Jonathan Kingston
Ehsan Akhgari
Barret Rennie
Makoto Kato
Sylvestre Ledru
Carl Corcoran
Narcis Beleuzu
Hiroyuki Ikezoe
Brindusan Cristian
Adam Gashlin
Thomas Wisniewski
Ciure Andrei
Doug Thayer
Jeff Gilbert
Masayuki Nakano
Cosmin Sabou
Emilio Cobos Álvarez
Dorel Luca
Kris Maglione
Marco Bonardo
Xidorn Quan
Chris Peterson
Bob Owen
Boris Zbarsky
James Teh
Milan Sreckovic
Andrea Marchesini
Wes Kocher
Sebastian Hengst
Bill McCloskey
Samael Wang