The two-argument versions are clearer and easier to use because they
work for any pair of writing mode and logical margin.
Differential Revision: https://phabricator.services.mozilla.com/D95371
The one-argument SetComputedLogicalMargin(),
SetComputedLogicalBorderPadding(), and SetComputedLogicalPadding() are
not changed because the next part are going to delete them.
Note that I'm deliberately not making ComputedLogicalMargin() and others
to return `const LogicalMargin&` because the compilers can use RVO to
eliminate unnecessary copy. If we'd like to convert them to accept all
writing mode like `nsIFrame::GetLogicalUsedMargin(WritingMode)` so that
the caller don't need to call `ConvertTo`, they can't return a const
reference anyway.
Differential Revision: https://phabricator.services.mozilla.com/D95370
Similar to the optional aContainingBlockSize parameter, both border and
padding should use logical coordinates in ReflowInput::mFrame's writing
mode.
Table frames that need to override border and padding can be simplified a bit.
However, DR_init_constraints_cookie and DR_init_offsets_cookie become more
complex, but they're only for debugging. I'm not planning to update their
internal APIs.
Differential Revision: https://phabricator.services.mozilla.com/D95369
I favor two-argument SetComputedLogicalMargin() for clarity in this
patch series because it works for any pair of writing mode and logical
margin.
Spoiler alert: the one-argument SetComputedLogicalMargin() will be
removed in a later part.
Differential Revision: https://phabricator.services.mozilla.com/D95366
This is a pure rename to make the argument meaning clearer. In the later
parts, we might use `wm` as an alias to
SizeComputationInput::mWritingMode. It's important to differentiate
between mWritingMode and containing block's writing mode.
Differential Revision: https://phabricator.services.mozilla.com/D95365
- We have an assumption that SetResponseHeaders will be called before WriteSegments is called for the first time. I would like to make it more structural add add a new state BEFORE_HEADERS
- mDataReceived was never set, which is wrong.
- Almost any error that occurs during ReadResponseData is a connection error and neqo will handle it internally by closing the session. This will be read by necko as ConnectionState change event. Therefore ignore errors received from mHttp3Connection->ReadResponseData and let the ConnectionChange event close the stream.
- This also adds a test. Because the stream has received some data already the transaction will br closed with the NS_ERROR_NET_PARTIAL_TRANSFER error.
Differential Revision: https://phabricator.services.mozilla.com/D94951
This will allow us to make response that violate the Http3 protocol and cause a protocol error.
Currently the server returns only one response, we may extend it if needed.
Differential Revision: https://phabricator.services.mozilla.com/D94912
- This will make handling of responses contain only headers in the same way as the responses with
a response body
- This will also make sure we pick up an error if neqo_http3conn_read_response_data return one.
Differential Revision: https://phabricator.services.mozilla.com/D94834
This matches other browsers, and common sense to some extent.
The code is a bit awkward because I want this behind a pref for now, as
it's not precisely a zero-risk change.
Differential Revision: https://phabricator.services.mozilla.com/D95065
No changes to behaviour. This splits the useOffThreadParseGlobal flag into
cases that care about the format and cases that care about the GC.
Depends on D95380
Differential Revision: https://phabricator.services.mozilla.com/D95381
Instead of relying directly on the UseOffThreadParseGlobal() flag to
determine the format of the XDR buffer, refactor to add useStencilXDR
locals to use. In the future, we can hook this to a different condition that
is independant of the parse-global status.
Also move the encoding of stencil until after instantiation for simplicity.
In the past, instantiation would mess with the stencil, but that has been
resolved now.
Depends on D95379
Differential Revision: https://phabricator.services.mozilla.com/D95380
If there's a device error trying to read some of the data from a font, it's better to catch the exception
and leave that individual font unusable (without names or character map) than to crash the whole process.
Differential Revision: https://phabricator.services.mozilla.com/D95146