Hi caseq@. PTAL. I'm evaluating this one for M144 LTS but I ran into this fuchsia-binary-size problem spotted by the bots. Do you believe this is fine, specially for the sake of backport merge? Thank you very much.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
Hi caseq@. PTAL. I'm evaluating this one for M144 LTS but I ran into this fuchsia-binary-size problem spotted by the bots. Do you believe this is fine, specially for the sake of backport merge? Thank you very much.
Interesting, I don't think we've seen a comparable increase on trunk (https://chromium-review.git.corp.google.com/c/chromium/src/+/7595948), it's some 568 bytes for android apks and even shows negative for Fuchsia. I'm not sure if the bot can be trusted here given compressed increase >> uncompressed increase.
Anyway, I'm not sure if you want this for LTS -- technically, this approach turned out to be against the spec (we're instead supposed to treat detached arrays as empty, although in reality it would only manifest in specially crafted corner cases that are rarely useful outside of trying to write an exploit).
We ended up revising this after quite a bit of trial-and-error :-/
You may want to consider the following CLs instead:
https://chromium-review.googlesource.com/c/chromium/src/+/7746207
https://chromium-review.googlesource.com/c/chromium/src/+/7737852
https://chromium-review.googlesource.com/c/chromium/src/+/7677065
I'm stamping this one nevertheless if you still choose to go with it.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |