Behind a pref of course. Toggle that pref on on the loading/lazyload test
subdirectory, though there are no tests for the IDL (I guess once the spec PR
lands the existing IDL tests will be updated from the spec).
Differential Revision: https://phabricator.services.mozilla.com/D59764
--HG--
extra : moz-landing-system : lando
The changes to the IDL files were done by running this in dom/webidl:
perl -pi -e 'BEGIN { $/ = undef; } s/\[HTMLConstructor,\n Exposed=Window\]\ninterface ([A-Za-z]+) : HTMLElement \{/[Exposed=Window]\ninterface \1 : HTMLElement {\n [HTMLConstructor] constructor();\n/g' *.webidl
and then fixing any remaining parser failures. That involved hand-editing the
following files:
TestCodeGen.webidl
XULFrameElement.webidl
XULMenuElement.webidl
XULTextElement.webidl
XULTreeElement.webidl
HTMLAudioElement.webidl
HTMLDialogElement.webidl
HTMLElement.webidl
HTMLEmbedElement.webidl
HTMLFormElement.webidl
HTMLImageElement.webidl
HTMLObjectElement.webidl
HTMLOptionElement.webidl
HTMLSlotElement.webidl
HTMLVideoElement.webidl
XULElement.webidl
XULPopupElement.webidl
Differential Revision: https://phabricator.services.mozilla.com/D49349
--HG--
extra : moz-landing-system : lando
For review purposes, the important changes are in dom/bindings/Configuration.py
and dom/bindings/parser.
The changes to the IDL files were done by running these in dom/webidl
and dom/bindings/test:
perl -pi -e 's/^interface ([A-Za-z0-9_]+)($| [:{])/[Exposed=Window]\ninterface \1\2/' *.webidl
perl -pi -e 'BEGIN { $/ = undef; } s/\[HTMLConstructor\]\n\[Exposed=Window\]/[HTMLConstructor,\n Exposed=Window]/g' *.webidl
perl -pi -e 'BEGIN { $/ = undef; } s/\[NoInterfaceObject\]\n\[Exposed=Window\]/[NoInterfaceObject,\n Exposed=Window]/g' *.webidl
perl -pi -e 'BEGIN { $/ = undef; } s/\[ChromeOnly\]\n\[Exposed=Window\]/[ChromeOnly,\n Exposed=Window]/g' *.webidl
And running this in dom/chrome-webidl:
perl -pi -e 'BEGIN { $/ = undef; } s/\[ChromeOnly\]\ninterface/[ChromeOnly, Exposed=Window]\ninterface/g' *.webidl
and then fixing all the resulting parser failures. I then verified that the
generated code is the same as before this change.
Differential Revision: https://phabricator.services.mozilla.com/D46697
--HG--
extra : moz-landing-system : lando
The img decode API allows a web author to request that an image be
decoded at its intrinsic size and be notified when it has been
completed. This is useful to ensure an image is ready to display before
adding it to the DOM tree -- this will help reduce flickering.
Differential Revision: https://phabricator.services.mozilla.com/D11362
This patch was generated by my modeline.py script.
MozReview-Commit-ID: EbVjPLwiUAT
Depends on D4159
Differential Revision: https://phabricator.services.mozilla.com/D4161
--HG--
extra : moz-landing-system : lando
ImageLoadingContent.currentURI returns the "URI" of currentRequest, which is
the URI used to start that request. Some consumers need to know the final URI
of that request instead.
If the image request gets redirected on loading (e.g. an add-on intercepts the
request), currentRequestFinalURI will be the redirected URI, while currentURI
would be the original URI before redirect.
MozReview-Commit-ID: 9lX063uAIp1
--HG--
extra : rebase_source : 91451128abc5c3f29c11d3cabfc98cde6c440ea6
ImageLoadingContent.currentURI returns the "URI" of currentRequest, which is
the URI used to start that request. Some consumers need to know the final URI
of that request instead.
If the image request gets redirected on loading (e.g. an add-on intercepts the
request), currentRequestFinalURI will be the redirected URI, while currentURI
would be the original URI before redirect.
MozReview-Commit-ID: 9lX063uAIp1
--HG--
extra : rebase_source : 6e9752b4df52e3874815557fe727c3fe94af2902