- Remove nsDragService::CreateURIList() and replace it by nsDragService::SourceDataGetUriList().
It reads all items from nsITransferable and put them to uri list.
If data drop is performed to another application which doesn't have access to internal data storages (mailbox:// for instance),
request download and save referenced items to /tmp directory.
- Implement SourceDataAppendURLItem() which read one item from nsITransferable and append it to uri list.
Download and store internal files in /tmp directory.
- Make CreateTempFile() to block native events processing. nsIOutputStream/nsIInputStream read and write operations run
event loop and can abort D&D operation before we write all data to /tmp. Use nsAppShell to block native event processing
during read/write to prevent it.
Differential Revision: https://phabricator.services.mozilla.com/D162473
So that APZ can wait to handle the event to do overscrolling until the browser
responds that the event wasn't used for gestures.
Differential Revision: https://phabricator.services.mozilla.com/D160438
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
And initialized it only in ctors so that in the next change we can use it to
tell whether this pan event may trigger swipe or not without calling
SwipeTracker::CanTriggerSwipe every time.
There's an unintuitive change in a GTest sending a horizontal pan-start event.
With this changeset, all incomming pan-start events on desktop platforms
basically set mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection
to true even if the event is generated in GTests. So the pan start event runs
into the short circuit path for swipe-to-navigation. This is a good thing because
it means the GTest replicates what our browser does properly.
Differential Revision: https://phabricator.services.mozilla.com/D160435
There's a bug (bug 1800022) that wheel event listeners in the browser process
badly interact with overscroll even so we'd avoid the bug here.
Differential Revision: https://phabricator.services.mozilla.com/D161752
Otherwise prefs set in the previous test case will persist. In fact
some of test cases were lacking "browser.swipe.navigation-icon-move-distance".
Differential Revision: https://phabricator.services.mozilla.com/D161751
The stuff calls PanGestureBlockState::SetNeedsToWaitForContentResponse which sets
mWaitingForContentResponse flag, but the flag will clobbered in
MaybeRequestContentResponse().
Differential Revision: https://phabricator.services.mozilla.com/D160432
This adds a subcommand ./mach cargo udeps with the following
sub command arguments:
Sub Command Arguments:
--all-crates Check all of the crates in the tree.
crates The crate name(s) to check.
--jobs [jobs], -j [jobs]
Run the tests in parallel using multiple
processes.
-v, --verbose Verbose output.
--message-format-json
Emit error messages as JSON.
--expect-unused Do not return an error exit code if udeps
detects unused dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D159838
This makes Merino opt out on Beta. There are two different parts:
1. Decide what "Beta" means. After discussing this with RyanVM, I'm using the
same definition [used by telemetry](https://searchfox.org/mozilla-central/rev/2f47e3dacf0d773e9c7f363cecf10cfbea490679/toolkit/components/telemetry/app/TelemetryControllerBase.jsm#103,112-114): (a) if `MOZ_UPDATE_CHANNEL` is "beta"
or (b) if it's "release" and `app.update.channel` is "beta". The latter case
is true for RC builds delivered to the Beta channel. I moved the relevant
telemetry logic to `AppConstants` so I can easily use it too. Bug 1435753 has
context on this logic w/r/t telemetry.
2. Change the Merino default so it's enabled on Beta in the offline scenario. I
kept the online scenario's disabled default since the only point of
delivering the online scenario to the user now is to prompt them to opt in to
Merino. This change is in UrlbarPrefs.sys.mjs.
The rest of the patch updates tests.
The effect of this patch will be to use a new default value of true for the
`quicksuggest.dataCollection.enabled` pref on Beta in the offline scenario. If
the user didn't touch the pref at all, then its previous default value was
false, and the new default will now be true.
If the user enabled the pref, it will remain enabled. If the user enabled and
then disabled it, it will remain disabled. That's because the pref is sticky, so
once it has a value on the user branch, it will keep that value. This patch only
changes the value of the pref on the default branch, so it won't override the
user's previous choice since that is set on the user branch.
Differential Revision: https://phabricator.services.mozilla.com/D162353
Some paths may contain so many types that their vertex representation far exceeds their
software rasterized representation in memory size. As a sanity-check, we should just set
a hard limit on the maximum allowed complexity of a path that we attempt to supply to
wpf-gpu-raster. Beyond that, we will instead just rasterize in software and upload
to a texture which can be more performant.
Differential Revision: https://phabricator.services.mozilla.com/D162481
This never really belonged in XULMenuItemAccessibleWrap::Name, as it's specific to MSAA.
This will allow us to remove this Wrap class.
Differential Revision: https://phabricator.services.mozilla.com/D162455
It was not installed consistently across platforms, and I think the only
reason we installed it had been superseded by the `mach uuid` command
(which didn't rely on it), and the `mach uuid` command was removed in
bug 1639509.
Differential Revision: https://phabricator.services.mozilla.com/D162636
One thing to note is that if the user shrinks this number we won't reclaim any memory - this is because I wanted to avoid doing any more work than necessary when we're logging messages. Let me know if you think this is a problem!
Differential Revision: https://phabricator.services.mozilla.com/D161156
At :handyman's suggestion, just removing the messages when we get a WM_DESTROY message works great and is way less complicated than the previous version of this :-)
Differential Revision: https://phabricator.services.mozilla.com/D161155
This is the list of messages that handyman and rkraesig suggested.
Since we're recording WM_GETMINMAXINFO, we now have better logging for that message.
Differential Revision: https://phabricator.services.mozilla.com/D161150
This is helpful for the normal event log, and also necessary since we want to group the messages up by window in the about page.
Differential Revision: https://phabricator.services.mozilla.com/D161149
When a selection event is dropped due to coalescence, we still include the impacted Accessible in the SelectedAccessiblesChanged notification we send to the parent process.
Although we skip events with defunct targets, we weren't skipping defunct items referenced by selection events.
This meant that if an Accessible was selected/unselected but was shut down before we sent SelectedAccessiblesChanged, the notification would include a dead Accessible.
This was causing an assertion in the parent process.
To fix this, we now ignore defunct items in selection events.
Differential Revision: https://phabricator.services.mozilla.com/D162551
