This lets us encode updated expectations for these scenarios (based on more
web=compatible soon-to-be-proposed spec text[1]) right now in
naturalWidth-naturalHeight-width-height.tentative.html, while letting
naturalWidth-naturalHeight.html continue to encode the expectations of current
spec text for the time being.
(Note that some of the scenarios in the older test are already tested in the
newer test and hence don't need to be copied over.)
[1] https://github.com/whatwg/html/issues/11287
Original Revision: https://phabricator.services.mozilla.com/D251970
Differential Revision: https://phabricator.services.mozilla.com/D267121
I originally created this test as a placeholder to test some edge cases where
the naturalWidth and naturalHeight might be unavailable (hence "unavailable" in
the name), with the intent of ultimately merging it back into
naturalWidth-naturalHeight.html once
https://github.com/whatwg/html/issues/11287 was resolved.
However, I'm now planning for this test to just be the canonical test
for the img.{naturalWidth,naturalHeight,width,height} attributes, for a variety
of scenarios (not just ones where the natural width/height might be
unavailable). Then we can remove the naturalWidth-naturalHeight.html test
entirely (obsoleted by this test) when the spec change is complete.
This patch is the first part of this -- just renaming the test and updating
the title to reflect its new broader purpose.
Original Revision: https://phabricator.services.mozilla.com/D251969
Differential Revision: https://phabricator.services.mozilla.com/D267120
This is just cleanup and doesn't change the behavior of this test. The img
elements here are 'display:block', so:
* 'vertical-align' doesn't apply.
* 'width:max-content' is basically redundant, since block-level replaced
elements already size to their max-content size.
Hence, I'm removing these unnecessary styles.
(I re-ran the test in both Firefox and Chrome to make sure the results don't
change.)
Original Revision: https://phabricator.services.mozilla.com/D251934
Differential Revision: https://phabricator.services.mozilla.com/D267119
This patch doesn't fundamentally change the behavior or expectations of this
test.
This patch simply moves all of the img elements to a <template> (which is not
rendered), and then appends a clone of those elements to a container within
the body; and then those cloned img elements are what get tested.
This sets the stage for later patches to append additional modified copies of
these img elements, with small modifications (e.g. using 'srcset' rather than
'src').
Original Revision: https://phabricator.services.mozilla.com/D251659
Differential Revision: https://phabricator.services.mozilla.com/D267118
While reverting all the work related to cross platform escaping of curl (See Bug 1976589), i tried to cleanup the
escaping of new line characters, but introduced carriage returns (\r).
This patch reverts back to the original fix from Bug 1968414
Original Revision: https://phabricator.services.mozilla.com/D265397
Differential Revision: https://phabricator.services.mozilla.com/D267045
This patch reverts important parts of D243110 related to Bug 1950001
This goal is for the Copy As Curl(Windows) to work properly on just the windows CMD
Differential Revision: https://phabricator.services.mozilla.com/D255793
- This patch should revert the fixes from Bug 1960198, Bug 1949994 and Bug 1962301.
- The goal of this patch is Copy as curl (POSIX) should only work on Linux.
Differential Revision: https://phabricator.services.mozilla.com/D255784
Normally we expect timer creation/initialization to be infallible, but there appear to be rare cases where it fails.
It would be good to understand the cause, but first of all we should honor the return value in case of error.
Note that allocations during timer init are infallible since bug 1961386, so most likely the cause is not running low on memory.
Original Revision: https://phabricator.services.mozilla.com/D262593
Differential Revision: https://phabricator.services.mozilla.com/D266578
The patch to bug 1979546 refactored the logic that awaits the process
termination. The logic that processes process termination should stop
the poll loop() via updatePollEvents(). This did not happen, because
updatePollEvents() considered a process alive if it is in
`io.processes`, but the updatePollEvents() was not called when
`cleanupProcess` cleared the last reference.
Consequently, the poll loop continued forever if the process's pipes
closed before the process.
Original Revision: https://phabricator.services.mozilla.com/D261060
Differential Revision: https://phabricator.services.mozilla.com/D266338
The current WaitForMultipleObjects-based implementation causes a
deadlock if 16 or more processes are spawned, as explained in the bug.
This patch replaces the use of events and WaitForMultipleObjects with
I/O Completion Ports (IOCP) as the mechanism to monitor I/O progress
and process terminations. This is not subject to the
MAXIMUM_WAIT_OBJECTS (64) limit of WaitForMultipleObjects.
Original Revision: https://phabricator.services.mozilla.com/D258968
Differential Revision: https://phabricator.services.mozilla.com/D266337
