There was a warning message displayed to indicate that
the stylesheets where parsed again for checking errors,
and that in order to see errors for CSS modified in
Javascript, the tab should be reloaded.
The jargon used there was confusing, and also this was
more a notice than an actual warning message.
In order to remove confusion, we don't emit this message
anymore, but add a title to the CSS filter button when
it's disabled. The sentence is reworded to be simpler
to understand.
Differential Revision: https://phabricator.services.mozilla.com/D44118
--HG--
extra : moz-landing-system : lando
Because it's violated when updates occur, and when the violation occurs it's
safe to continue, for reasons explained in the patch. This should fix a top
crash.
Differential Revision: https://phabricator.services.mozilla.com/D44102
--HG--
extra : moz-landing-system : lando
This is done by modifying the evaluateExpression action,
where we retrieve the selection of the full input.
Differential Revision: https://phabricator.services.mozilla.com/D43750
--HG--
extra : moz-landing-system : lando
Test is in the other revision for this bug.
Do the same we do for the other bits. This setup looks pretty error prone
though...
Differential Revision: https://phabricator.services.mozilla.com/D44069
--HG--
extra : moz-landing-system : lando
`LineBreaker` splits sequences of characters not containing whitespaces,
which is undesirable for CJK-strings. In that case, `LineBreaker` is
deliberately not used and lines are only broken at ASCII-whitespace
characters.
Differential Revision: https://phabricator.services.mozilla.com/D43963
--HG--
extra : moz-landing-system : lando
For developing properties, we will handle them in an other bug.
Besides, I use an iframe for the test because we create a use counter in
the constructor of Document, which use the prefs to decide what kind of
properties we want to record. So, in the test, we have to reload iframe
to make sure we re-create the document, so does the use counter, to make
sure the prefs work properly.
The two prefs affect the css use counters:
1. layout.css.use-counters.enabled: Allocate use counters, and record
non-custom properties.
2. layout.css.use-counters-unimplemented.enabled: Record all unimplmented
properties into the use counters.
If we disable layout.css.use-counters.enblaed, we don't create use counters
object, so layout.css.use-counters-unimplemented.enabled doesn't work,
either.
Differential Revision: https://phabricator.services.mozilla.com/D43860
--HG--
extra : moz-landing-system : lando
I made the left and right padding in compact mode on the bookmarks toolbar smaller,
so that the first favicon lines up with the back button and the see more bookmarks button
lines up with the main menu.
Differential Revision: https://phabricator.services.mozilla.com/D43775
--HG--
extra : moz-landing-system : lando
Use non-breaking space for some strings to avoid wrapping a single (widowed) word to its own line.
Differential Revision: https://phabricator.services.mozilla.com/D44039
--HG--
extra : moz-landing-system : lando
The mar utility stores MOZ_APP_VERSION as the default Product Version for mar creation. So mar should be rebuilt whenever the milestone changes.
Differential Revision: https://phabricator.services.mozilla.com/D44089
--HG--
extra : moz-landing-system : lando
When focused on a toolbar button, users can now type the first (or first few) characters of another button's name to jump directly to that button.
The search characters are cleared after 1 second or if a non-character key is pressed.
This is similar to the typed character navigation implemented for HTML select controls.
Differential Revision: https://phabricator.services.mozilla.com/D43187
--HG--
extra : moz-landing-system : lando
MOZ_FULL_PRODUCT_VERSION is only used here, while tools/update-packaging/make_full_update.sh expects MOZ_PRODUCT_VERSION.
Depends on D44089
Differential Revision: https://phabricator.services.mozilla.com/D44090
--HG--
extra : moz-landing-system : lando
For OOP iframes, sometimes, AddChildDoc gets called before the embedder sends us the OuterDocAccessible.
Previously, we crashed when this occurred.
Now, we add the child when the OuterDocAccessible proxy gets created later.
Differential Revision: https://phabricator.services.mozilla.com/D42798
--HG--
extra : moz-landing-system : lando
The mar utility stores MOZ_APP_VERSION as the default Product Version for mar creation. So mar should be rebuilt whenever the milestone changes.
Differential Revision: https://phabricator.services.mozilla.com/D44089
--HG--
extra : moz-landing-system : lando
This commit extends the jit-test runner to support
'skip-variant-if: $FLAG, $COND', and uses this to not run
'--wasm-disable-huge-memory' tests when the platform doesn't support huge
memory.
Differential Revision: https://phabricator.services.mozilla.com/D43670
--HG--
extra : moz-landing-system : lando
We can't deserialize code that doesn't contain bounds checks if we have
dynamically switched to not using huge memory. This commit uses BuildID to
invalidate cached code correctly.
Differential Revision: https://phabricator.services.mozilla.com/D41870
--HG--
extra : moz-landing-system : lando
This commit modifies WasmMemoryObject, ArrayBufferObject,
SharedArrayBufferObject to support conditionally using huge memory based on the
global flag.
The memory logic is fairly involved and entangled, making this change a bit
tricky.
The following changes were made:
* Stopped conditionally compiling huge memory constants and prefixed them with `Huge`
* Stopped conditionally compiling `ExtendBufferMapping` and `wasmMovingGrowToSize`
* Renamed `CreateBuffer` to `CreateSpecificWasmBuffer`
* For clarity
* Moved maxSize clamping into `CreateSpecificWasmBuffer`
* Lets us keep one callsite to `wasm::IsHugeMemoryEnabled` during memory creation
* Moved mappedSize computation out of `RawbufT::Allocate` to `CreateSpecificWasmBuffer`
* Lets us keep one callsite to `wasm::IsHugeMemoryEnabled` during memory creation
* Moved `boundsCheckLimit` computation from `ArrayBufferObjectMaybeShared` to `WasmMemoryObject`
* Lets WasmMemoryObject be responsible for knowing whether it is 'huge' or not
* Added method to determine if a `WasmMemoryObject` is huge or not
* Lets use know whether we support `movingGrow` or have a `boundsCheckLimit`
* Refactored `WasmMemoryObject::grow` to have one callsite to `wasmMovingGrowToSize`
* For clarity
* Added release assert in `Module::instantiateMemory`
* Ensures we have a huge memory or bounds checks if needed
Differential Revision: https://phabricator.services.mozilla.com/D41869
--HG--
extra : moz-landing-system : lando
This commit allows us to conditionally compile bounds checks based on runtime
support for huge memory.
New flags to CompileArgs and CompilerEnvironment are added for whether we are
using huge memory or not, and computed based on the global flag.
Differential Revision: https://phabricator.services.mozilla.com/D41868
--HG--
extra : moz-landing-system : lando