According to the Microsoft documentation, this is the maximum length
of the string allowed for the description property of an IShellLinkW.
This also adds a test for long descriptions to ensure that they are
properly truncated.
This patch also:
- Adjusts the tests a little bit to be less race-y, particularly with the
SetAppID routine in the JumpListBuilder constructor.
- Fixes the issue where the tests weren't properly copying in the intended
strings for test titles and descriptions.
Differential Revision: https://phabricator.services.mozilla.com/D193693
We use a mock JumpListBackend to act as a stand-in for the win32 API
for populating the JumpList, and test that it gets called with the
expected arguments for each major function of JumpListBuilder.
Differential Revision: https://phabricator.services.mozilla.com/D189407
In practice, we have never enabled showing the "Recent" list in the Jump
List, and have only ever shown "Frequent" by default. For now, we only
implement "Frequent".
The "Frequent" SQL query was derived by examining
nsNavHistory::ConstructQueryString and deriving the resulting SQL
query string that the original frequent visits query was using.
This is as opposed to using the actual original buildFrequent
routine, as that uses deprecated Places APIs.
Differential Revision: https://phabricator.services.mozilla.com/D189406
1. Adding mAsyncWaitAlgorithms to match mAsyncWaitWorkerRef and keep the algorithms object just like how the workerref is kept right now.
2. Closing mInput also on the window teardown, to prevent memory leak as Fetch does not close the stream automatically.
Depends on D193295
Differential Revision: https://phabricator.services.mozilla.com/D190058
Although our implementation follows the intention of rfc6455#section-4.1, we can handle the described situation more gracefully by prioritizing new WS connections to paths that have _not_ previously failed.
Differential Revision: https://phabricator.services.mozilla.com/D193386
This is the first of two planned fixes. For bug 1850993 ("The link URL status bar often gets stuck on YouTube (persists into full screen mode and beyond)"), I want to make it so that we invalidate any existing status as we go fullscreen, without suppressing new overlink statuses while in DOM fullscreen; I checked Chrome and it shows overlink statuses in DOM fullscreen too.
Differential Revision: https://phabricator.services.mozilla.com/D193922
Includes only support for dynamically loading style sheets from `<link>`
elements and `Link` header fields.
The remaining support, including preloading, is completed in part 3.
Differential Revision: https://phabricator.services.mozilla.com/D191745
This patch adds a transform that applies the backstop optimization strategy to all perftest tasks. At the same time, the tier for all perftest tasks is limited here to tier 2, and 3. We shouldn't have any tier 1 tasks running at this stage.
Differential Revision: https://phabricator.services.mozilla.com/D194378
* Add histogram to sessionrestore code to count how often and the number of
closed tabs that aren't saved on window close due to no open saveable tabs
* Add test coverage
Differential Revision: https://phabricator.services.mozilla.com/D193055
See the profile in the blocked bug, this is about half of the time spent
there. It doesn't help with the json serialization being slow (maybe
huge object graph?), but should be an easy win.
Differential Revision: https://phabricator.services.mozilla.com/D194476
For the selector, property name and property value editors, we don't want the
Enter key to trigger editing the next inplace editor.
We only want to close the current editor and focus the associated element so the
user can use regular keyboard navigation.
We still want the Tab key to trigger "editor navigation", so we pass the appropriate
options to editableField.
Existing test that were not specifically asserting the moving focus behaviour
are updated. If they were using Enter only to commit and move to the next input,
we update them to use Tab instead.
Differential Revision: https://phabricator.services.mozilla.com/D193287
By default, when hitting Tab (and Enter if `stopOnReturn` is false), the focus
is moved to the next (previous if Shift+Tab) focusable element.
If such element is also an inplace editor, then we trigger the editing.
Here, we're adding options so the focus will try to move to the next inplace
editor, even if there are other focusable items before it.
When the option is set to true, we require a mandatory selector that matches
an element onto which we are searching for inplace editors to focus, so we
don't move the focus indefinitely.
Differential Revision: https://phabricator.services.mozilla.com/D193194
Using a XUL iframe introduces some flickering with about:blank that I
don't think I want to dig into much. Just use HTML here.
Depends on D194394
Differential Revision: https://phabricator.services.mozilla.com/D194395
* Add a type=page to the top-level ViewPage instances
* Rename viewTabVisibleCallback and viewTabHiddenCallback to view*Callback and call each when selectedness or visiblity changes
* Ensure active view/pages are always properly initialized during page load and category switching
* Add a test to verify no mutations happen when tabs change while firefox view is inactive
* Fix tests to better account for loading and readiness sequence when activating firefox view
Differential Revision: https://phabricator.services.mozilla.com/D193744
Alex Jakobi
Mike Conley
Stanca Serban
Manuel Bucher
Katherine Patenio
Kagami Sascha Rosylight
Narcis Beleuzu
Emilio Cobos Álvarez
Andrew Creskey
Jim Blandy
Dão Gottwald
Mirko Brodesser
Yury Delendik
ffxbld
Greg Mierzwinski
Julien Cristau
James Hendry
Sarah Clements
Luca Greco
Kershaw Chang
Nicolas Chevobbe
Tiaan Louw
Jan Horak
Valentin Gosu
Sam Foster