A mDisplay vs mImage mixup. We also set both values in CreateTrackInfoWithMIMETypeAndContainerTypeExtraParameters to prevent similar issues in the future.
Differential Revision: https://phabricator.services.mozilla.com/D3788
--HG--
extra : moz-landing-system : lando
Re-introduces support for setting remote icons provided a loading principal is
passed. Removes some now defunkt code from sessionstore.
Differential Revision: https://phabricator.services.mozilla.com/D3123
--HG--
extra : moz-landing-system : lando
Count number of requests/streams per connection done when the connection
was used for TRR.
MozReview-Commit-ID: H7X06h8gVZY
Differential Revision: https://phabricator.services.mozilla.com/D3589
--HG--
extra : moz-landing-system : lando
In this bug, we will focus on the problem of cannot download PDF file from google drawing successfully on MAC.
After investigating, I found that "SetTarget()" is called twice with two different addresses.
However, they both point to the same file.
We will assign the first target to "mInitialTarget" and the second one to "mRenamedTarget".
This problem happened when doing the second "SetTarget()".
After canceling the existing AsyncCopy, we will schedule a new AsyncCopy.
However, we only assign the mActualTarget with mRenamedTarget when they point to different files.
In this case, the two different addresses point to the same file.
So the mActualTarget is still the same as mInitialTarget.
After completion of the AsyncCopy, we try to do "CheckCompletion".
But it will always return false due to "mRenamedTarget exists" and "mActualTarget" is not the same as "mRenamedTarget".
The solution is quite easy.
We should always update mActualTarget with renameTarget, even if they point to the same file.
Differential Revision: https://phabricator.services.mozilla.com/D3400
--HG--
extra : moz-landing-system : lando
This unbreaks some tier 3 raptor tasks. There are a few fixes rolled together here:
1) Stop overwriting the 'env' in mozharness_test.py's 'native-engine' implementation
2) Set the workdir to /home/cltbld (which makes sure the fetches are downloaded to there)
3) Download the fetches via mozharness in the 'raptor' script (since they don't use run-task anymore)
Depends on D3651
Differential Revision: https://phabricator.services.mozilla.com/D3652
--HG--
extra : moz-landing-system : lando
We need to grab fetches from several place in mozharness, this creates a
dedicated mixin that can be used from anywhere. If the 'fetch-content' script
is detected that will be used, otherwise we download the fetches manually.
Differential Revision: https://phabricator.services.mozilla.com/D3651
--HG--
extra : moz-landing-system : lando
this combines the changes that I made in bug 1464461
(https://reviewboard.mozilla.org/r/253132/diff/1#index_header) with the changes for web replay made
by Brian Hackett, along with some clean up that was done by Honza with regards to helpers being
executed. This change should not have any functional impact on the code base, but it should make it
easier to work with the evalWithDebugger functionality than it has been so far.
Differential Revision: https://phabricator.services.mozilla.com/D3311
--HG--
rename : devtools/server/actors/webconsole.js => devtools/server/actors/webconsole/eval-with-debugger.js
extra : moz-landing-system : lando
For some reason we might miss the initial focus event. This ensures the video
element is focused when the document loads.
Differential Revision: https://phabricator.services.mozilla.com/D3444
--HG--
extra : moz-landing-system : lando
MenuButton will listen the HTMLTooltip hidden event even if HTMLTooltip is
destroyed. As a result of it, the timer which issued in the MenuButton's event
listener might fail due to the target window is destroyed. (e.g., switching the
dock mode to bottom from window mode.)
This patch will remove this event listener before destroying the HTMLTooltip.
Differential Revision: https://phabricator.services.mozilla.com/D3759
--HG--
extra : moz-landing-system : lando
Even after we disable Gecko specific editing UIs by default, web apps can
enable them with execCommand. However, until such web apps change their
behavior, users cannot use Gecko specific UIs. At least for now, we should
make users can enable them by default.
MozReview-Commit-ID: AuAdw4FQ4He
--HG--
extra : rebase_source : a1f88f2928df0d7afb4361c425d75c74872ac9d5