This patch moves all the logic we currently have
baked-in JsTerm to handle the autocompletion data:
- deciding to fetch from the server or the cache
- handling concurrent requests
- managing the cache.
This is now done through dedicated Redux actions and reducers.
In the JsTerm, where the autocompletePopup still lives, we
handle those data changes in componentWillReceiveProps.
Some tests were modified in order to pass with these changes.
Differential Revision: https://phabricator.services.mozilla.com/D11454
--HG--
extra : moz-landing-system : lando
Previous to bug 1453751 favicons were loaded from the network by a <xul:image>
tag with validate="never". This caused us to always use any cached version if
possible. Bug 1453751 used a normal load type causing us to revalidate with the
server for each request. This switches the loader to using the cache if possible.
Differential Revision: https://phabricator.services.mozilla.com/D11402
--HG--
extra : moz-landing-system : lando
In some cases, the setTimeoutIfNeeded function can
be called before the store is initialized, which is
causing an exception when we try to dispatch the
messages.
With this patch, we check if the store is not ready,
and re-schedule a timeout so messages can be handled
properly when the store is ready.
Differential Revision: https://phabricator.services.mozilla.com/D11044
--HG--
extra : moz-landing-system : lando
Currently, build telemetry submits at random, approximately
every 10 `mach` invocations. This choice was made arbitrarily,
with no real reason in mind for that level of frequency.
After speaking with some of the data engineers in #telemetry,
it seems we should be able to send pings to the telemetry
pipeline far more frequently than we realized. This commit
removes the telemetry submission logic and causes clients
to attempt to send pings for every mach invocation. Pings
are still saved to the outgoing directory, in case of a
failure or in the case of offline `mach` runs.
Differential Revision: https://phabricator.services.mozilla.com/D11279
--HG--
extra : moz-landing-system : lando
While attempting to improve the build telemetry submission
logic, I found a bug in the way telemetry submission
works. Essentially the submission script was failing to
import any of the required packages (specifically
`mozbuild.telemetry` in this case) as the method used to
modify path was incorrect and the script was running outside
of the virtualenv. The invocation is also sending stdout
and stderr to `/dev/null`, making this problem even less obvious.
When I fixed the path modifications, I realized that `mozbuild`
imports will require a long chain of other imports
(and transitively, more `sys.path` modifications)
such as `which`, `mach`, `mozautomation`, etc to complete.
When I tested the submission script, I did so by running
`mach python build/submit_telemetry_data.py`, which runs the
script in a virtualenv with all required packages installed.
That's likely part of the reasons I overlooked this issue in testing.
Rather than go through the process of importing every dependency
of `mozbuild`, this commit changes the invocation of the submission
script to go through `mach python`. Things seem to work as
expected with this change.
Differential Revision: https://phabricator.services.mozilla.com/D11278
--HG--
extra : moz-landing-system : lando
A subsequent commit will require similar logic to the
checks found in this command. Moving to mozbuild will
allow us to re-use the function instead of re-writing
similar logic.
Differential Revision: https://phabricator.services.mozilla.com/D11277
--HG--
extra : moz-landing-system : lando
X11.h defines a macro named "Bool", which can cause surprising compile errors due to include order.
Differential Revision: https://phabricator.services.mozilla.com/D11494
--HG--
extra : moz-landing-system : lando
In XPCShell tests, this `console` variable ends up being null and it later triggers an assertion
that makes the test crash in debug builds. We should always pass a defined object to this constructor.
MozReview-Commit-ID: F7QRXD15lH9
Depends on D11154
Differential Revision: https://phabricator.services.mozilla.com/D11445
--HG--
extra : moz-landing-system : lando
Even when execCommand("insertorderedlist") and
execCommand("insertunorderedlist") remove existing lists, we need to set
InputEvent.inputType value to "insertOrderedList" or "insertUnorderedList".
Fortunately, the XPCOM method is used only for handling
execCommand("insertorderedlist") and execCommand("insertunorderedlist") on
Firefox. Therefore, we should make it set EditAction to
EditAction::eRemoveOrderedListElement or EditAction::RemoveUnorderedListElement.
Note that comm-central uses this method directly and uses "cmd_removeList"
which causes calling the XPCOM method with empty string. However, input
events for them won't be exposed to the web. Therefore, it's okay to set
EditAction::eRemoveListElement for the other cases.
Differential Revision: https://phabricator.services.mozilla.com/D11439
--HG--
extra : moz-landing-system : lando
Both Chrome and Safari dispatches 2 sets of "beforeinput" and "input" events
when user drag and drop content in same editor. One is "deleteByDrag" and
the other is "insertFromDrop". We need to follow same behavior since
it should be able to cancel only "deleteByDrag" or "insertFromDrop" when
we implement "beforeinput" event.
HTMLEditor::InsertObject() may handle asynchronously. And we don't need to
do anything additionally for HTMLEditor. Therefore, TextEditor::OnDrop()
can delete selection before inserting dropped content by itself.
Therefore, this patch makes TextEditor::OnDrop() call
TextEditor::PrepareToInsertContent() and EditorBase::FireInputEvent() by
itself.
Unfortunately, it seems that we cannot write automated tests for this.
Even if using synthesizeMouse() of EventUtils, synthesizing mouse events
won't generate "dragover" nor "drop" events. Perhaps, like EventUtils.js,
we need to do something with drag service, but it means that we cannot
emulate drag and drop in an editor.
Differential Revision: https://phabricator.services.mozilla.com/D11285
--HG--
extra : moz-landing-system : lando
I also had to make some small changes to relazification for XDR tests for that to pass.
Differential Revision: https://phabricator.services.mozilla.com/D11587
--HG--
extra : moz-landing-system : lando
Only TextEditor::InsertTextAt() and HTMLEditor::DoInsertHTMLWithContext()
removes selected content before pasting from clipboard or inserting dropped
content, and they do same things. Therefore, they can share the code with
a helper method.
Note that this makes each root caller won't return NS_ERROR_EDITOR_DESTROYED
since the destruction is expected by web app.
Differential Revision: https://phabricator.services.mozilla.com/D11284
--HG--
extra : moz-landing-system : lando
All static functions from nsAccessibilityService that were either only called once from the markup map, or are simple one-liners that were only called up to three times, were converted to lambdas in the markup map.
the static function that creates HyperTextAccessibleWrap has remained untouched because it is called a lot from the markup map, even though its implementation is actually just a one-liner.
The other untouched static function is the templated one for html:dt or html:dd.
Differential Revision: https://phabricator.services.mozilla.com/D11458
--HG--
extra : moz-landing-system : lando
This makes sure we don't end up with stale entries with geometry clipped
to the previous mImageBounds on the receiving side.
The update code is duplicated for now but will hopefully be cleaned up
after the blob re-coordination work is done.
Differential Revision: https://phabricator.services.mozilla.com/D11566
--HG--
extra : moz-landing-system : lando
ConvertSampleToAnnexB takes the sample's out of band extradata to prepend it to the data. It was theorically possible that the first sample would contain the SPS/PPS from the previous format.
Depends on D11559
Differential Revision: https://phabricator.services.mozilla.com/D11560
--HG--
extra : moz-landing-system : lando
keyframe was tracked in the CodecChangeMonitor in order to determine when to prepend the SPS/PPS to a sample for decoder using AnnexB format.
The assumption was that it was needed only once per the lifetime of the decoder (and indeed this is true with the Windows and Android decoder). However this causes issue with the Widevine H264 decoder and it will error on some content if the first sample passed following a flush doesn't contain a SPS/PPS.
Interestingly, this issue isn't observed with Netflix content or other Widevine sample videos. Only Amazon PrimeVideo content so far.
We instead use the global MediaChangeMonitor keyframe status that knows when the decoder has been drained or flushed.
Differential Revision: https://phabricator.services.mozilla.com/D11556
--HG--
extra : moz-landing-system : lando
