This test was causing uplifts to fail because certain CSS properties
were disabled via preferences, and the devtools client and platform were
out of sync with what properties were supported. This test now uses the
preference information to allow in-development features to not break
this test.
MozReview-Commit-ID: 767xRFMHyw9
--HG--
extra : rebase_source : fb775f1e77f94fe506fe7a257a20ec4e4a9271fd
extra : histedit_source : deb70e12dee4c06ae5384360a5c87d6e5e5f75c9
Provide a single mach command to automatically generate the static
database of CSS properties that devtools uses for the inspector
and various editors.
MozReview-Commit-ID: 8E2jwxF0KbM
--HG--
rename : devtools/shared/css/moz.build => devtools/shared/css/generated/moz.build
extra : rebase_source : ab1815f321d460886168d95ddb739a579599b8c7
extra : histedit_source : f2bfecdcc128a87abcf3c0284a54c53bdeff1c87
This test was causing uplifts to fail because certain CSS properties
were disabled via preferences, and the devtools client and platform were
out of sync with what properties were supported. This test now uses the
preference information to allow in-development features to not break
this test.
MozReview-Commit-ID: 767xRFMHyw9
--HG--
extra : rebase_source : 55dbe214314f1fbe9933be982cbab7f2952bed85
Provide a single mach command to automatically generate the static
database of CSS properties that devtools uses for the inspector
and various editors.
MozReview-Commit-ID: 8E2jwxF0KbM
--HG--
extra : rebase_source : 2cd21cd08f431ff933c3fd89ebca3e6684fb80f8
In preparation for the additional files in the `mach generate-css-db`
command, collect the CSS files into a folder.
MozReview-Commit-ID: 9JRVsC2NMK8
--HG--
rename : devtools/shared/css-color-db.js => devtools/shared/css/color-db.js
rename : devtools/shared/css-lexer.js => devtools/shared/css/lexer.js
rename : devtools/shared/css-properties-db.js => devtools/shared/css/properties-db.js
extra : rebase_source : b73bbe7fcf8177a25b41ecdd6d6c760ed1472fb7
This change avoids lots of false positives for Coverity's CHECKED_RETURN
warning, caused by NS_WARN_IF's current use in both statement-style and
expression-style.
In the case where the code within the NS_WARN_IF has side-effects, I made the
following change.
> NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
> -->
> Unused << NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
In the case where the code within the NS_WARN_IF lacks side-effects, I made the
following change.
> NS_WARN_IF(!condWithoutSideEffects);
> -->
> NS_WARNING_ASSERTION(condWithoutSideEffects, "msg");
This has two improvements.
- The condition is not evaluated in non-debug builds.
- The sense of the condition is inverted to the familiar "this condition should
be true" sense used in assertions.
A common variation on the side-effect-free case is the following.
> nsresult rv = Fn();
> NS_WARN_IF_(NS_FAILED(rv));
> -->
> DebugOnly<nsresult rv> = Fn();
> NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Fn failed");
--HG--
extra : rebase_source : 58788245021096efa8372a9dc1d597a611d45611
This avoids loading the ellipsis properties file on browser startup.
MozReview-Commit-ID: 8lfAeltfn10
--HG--
extra : rebase_source : 11995c31fb4c9238777348e0c13b07888dd3ab0c
Create a helper designed to localize markup containing specific localization atttributes
(see the jsdoc in l10n.js)
MozReview-Commit-ID: 4ThyI1DaLQS
--HG--
extra : rebase_source : 3cb6620964c0dc27a348d4e85f93d437c2ad5d08
Localization properties files should not change during a session. To allow
callers to easily localize strings without having to instanciate LocalizationHelper
objects, we should cache the already required properties files.
This will for now only be used internally by the LocalizationHelper as well as
by the markup localization utility. But we could now use this to provide static
localization methods.
MozReview-Commit-ID: 85agGNJlIk9
--HG--
extra : rebase_source : 55ef18f371fa474e575ddc15d8e3b89ceca95d6b
This creates an easy interface for getting the static css database, and
splits up the initCssProperties function into smaller re-usable parts.
MozReview-Commit-ID: G86bNy3KQDp
--HG--
extra : rebase_source : 608df38114de31320594516ca776cc35ddb6ee8e
I explicitly did not migrate the localizations of the external properties file brand.properties.
This should be handled as part of Bug 1297733.
MozReview-Commit-ID: JXomOmr37xV
--HG--
extra : rebase_source : 0a4e25ba76748e159e389a7b6d42f6cf82d412aa
extra : intermediate-source : 44b1e19c5f2fc03d54ecba9507c30df4caff343f
extra : source : 2eee0a90aa25cae44f5bd1fb5c4d60438a6ceb54
The eyedropper can be shown in 2 distinct ways:
- the 'eyedropper' gcli command can be called (from the dev toolboar
or from the browser devtools menu),
- or the inspector's 'pickColorFromPage' method can be called (from
the inspector toolbar or from the color-picker in the ruleview).
Before this change, it was possible to show several eyedropper because
these 2 codepaths didn't know about each other.
Now, when executing the gcli command, the inspector's
'cancelPickColorFromPage' method is called to hide it first.
And, when the 'pickColorFromPage' method is called, the 'eyedropper --hide'
gcli command is called too.
This way, there's only one eyedropper shown.
There was also a problem where the gcli command would create a new
eyedropper everytime it was called. This was fixed too, by maintaining a
WeakMap of all eyedroppers opened so far.
MozReview-Commit-ID: F6fBP5R7ZTJ
--HG--
extra : rebase_source : f04bbf224ced7b93b4e5b0c42662731ecc58cb58
