The current properties selectedProfile and defaultProfile are somewhat confusing
selectedProfile actually returns the default profile for the build and
defaultProfile returns the default profile for non-dev-edition builds. This
confusion leads to callers doing the wrong thing in some places.
What most code actually cares about is being able to set/get the default profile
for this build and getting the current profile in use. So this patch replaces
the previous properties with currentProfile and defaultProfile which do what
makes more sense.
This patch also switches from using the preprocessor to change behaviour for
dev-edition builds to using a boolean flag since some code was incorrectly
ignoring the setting to make dev-edition use the same profile as normal builds.
In order to make currentProfile correct when resetting a profile I had to move
CreateResetProfile into nsToolkitProfileService.
Differential Revision: https://phabricator.services.mozilla.com/D16118
--HG--
extra : rebase_source : cefe252618cd3a1b0e0cd5a71b056dd2b557f1a3
extra : intermediate-source : 35af79575f54f75d22e213fdac7ddd704b40807a
extra : source : 732d1ce192408d4f595f2fce16f45c7354ce3097
The current properties selectedProfile and defaultProfile are somewhat confusing
selectedProfile actually returns the default profile for the build and
defaultProfile returns the default profile for non-dev-edition builds. This
confusion leads to callers doing the wrong thing in some places.
What most code actually cares about is being able to set/get the default profile
for this build and getting the current profile in use. So this patch replaces
the previous properties with currentProfile and defaultProfile which do what
makes more sense.
This patch also switches from using the preprocessor to change behaviour for
dev-edition builds to using a boolean flag since some code was incorrectly
ignoring the setting to make dev-edition use the same profile as normal builds.
In order to make currentProfile correct when resetting a profile I had to move
CreateResetProfile into nsToolkitProfileService.
Differential Revision: https://phabricator.services.mozilla.com/D16118
--HG--
extra : rebase_source : 24feb46363b5e43f35b51614d9dc6ae20ae49b65
extra : amend_source : 3c2051b98f19dc3288c59b0028db7d33c6953be3
extra : intermediate-source : 8404cc6140177a40c7086ddd4bf5d84735681048
extra : source : 732d1ce192408d4f595f2fce16f45c7354ce3097
Relevant divs are:
* Those that have an ID attribute. This is important so anchors still work.
* Those whose first or last child is a text-only node.
* Those whose first or last child has an inline frame.
We now discard divs that are not display:block; or display:inline-block;. We also discard divs that are part of an anonymous subtree.
We stop creating divs from the eHyperTextType frame type alltogether.
Note that because of shadow DOM properties in the video controls, two additional divs with IDs require role="none" in the media controls widget code.
Differential Revision: https://phabricator.services.mozilla.com/D17348
--HG--
extra : moz-landing-system : lando
Because custom elements will be constructed when DOM is constructed,
construct the DOM in the hidden panels will be expensive as we move
more and more widgets to custom elements from XBL.
This patch attempts to counter that by moving all the pane markups
into comment nodes, and use MozXULElement.parseXULToFragment() to
insert it when it is being asked.
They will be loaded lazily from an requestIdleCallback() in findInPage.js.
Differential Revision: https://phabricator.services.mozilla.com/D16787
--HG--
extra : moz-landing-system : lando
Relevant divs are:
* Those that have an ID attribute. This is important so anchors still work.
* Those whose first or last child is a text-only node.
* Those whose first or last child has an inline frame.
We now discard divs that are not display:block; or display:inline-block;. We also discard divs that are part of an anonymous subtree.
We stop creating divs from the eHyperTextType frame type alltogether.
Note that because of shadow DOM properties in the video controls, two additional divs with IDs require role="none" in the media controls widget code.
Differential Revision: https://phabricator.services.mozilla.com/D17348
--HG--
extra : moz-landing-system : lando
With all the dependency removed this pref can be safely removed.
Depends on D17574
Differential Revision: https://phabricator.services.mozilla.com/D17575
--HG--
extra : moz-landing-system : lando
This patch removes the datetimebox binding and always use
UA Widget for the job.
Depends on D17571
Differential Revision: https://phabricator.services.mozilla.com/D17572
--HG--
extra : moz-landing-system : lando
This patch removes the XBL videocontrols binding and make <video>
to always use the UA Widget to generate controls.
DevTools tests that look for NAC is switched to use <input type=file>.
Differential Revision: https://phabricator.services.mozilla.com/D17571
--HG--
extra : moz-landing-system : lando
This custom element replaces XBL <content> usage by directly prepend the two needed child nodes when the element is connected.
This is doable because
- There isn't any direct access of child nodes under <menulist>. Everyone seems to access via .menupopup, which is usually the only child.
- We don't need to move the children under <menulist>. If we need to and if the child is a <xbl:children> (which could happen if <menulist> is inside an XBL <content> that just get cloned to the document), the layout will get very confused and crash (see finding in bug 1514926)
Differential Revision: https://phabricator.services.mozilla.com/D16149
--HG--
rename : toolkit/content/widgets/menulist.xml => toolkit/content/widgets/menulist.js
extra : moz-landing-system : lando
Because custom elements will be constructed when DOM is constructed,
construct the DOM in the hidden panels will be expensive as we move
more and more widgets to custom elements from XBL.
This patch attempts to counter that by moving all the pane markups
into comment nodes, and use MozXULElement.parseXULToFragment() to
insert it when it is being asked.
They will be loaded lazily from an requestIdleCallback() in findInPage.js.
Differential Revision: https://phabricator.services.mozilla.com/D16787
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
The All Downloads view removes and re-adds its richlistbox for performance reasons.
However, after bug 1492326, this causes the richlistitem's .current property to be assigned before its binding is applied.
Since the .current property fires a11y focus events, this means this property is overridden and thus the events never get fired for that item.
To fix this, move a11y focus event firing into richlistbox.currentItem.
Differential Revision: https://phabricator.services.mozilla.com/D16932
--HG--
extra : moz-landing-system : lando
With the patch above we do find the input element, and try to autocomplete it
normally, which confuses some tests.
Differential Revision: https://phabricator.services.mozilla.com/D17143
--HG--
extra : moz-landing-system : lando
CSS visibility doesn't work like `display`. `visibility: visible` elements in a
`visibility: hidden` subtree still get shown.
Differential Revision: https://phabricator.services.mozilla.com/D17068
--HG--
extra : moz-landing-system : lando
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
sizetopopup is set to "pref" by default by the menulist XBL binding, however
when converting the binding to custom element, it did not set the attribute value
at a time that is early enough.
This patch updates nsMenuPopupFrame and nsMenuFrame so that it considers
<menulist> with unset sizetopopup attribute as equal to "pref" to avoid
the problem above.
This reftest
layout/reftests/xul/menulist-shrinkwrap-2.xul
can detect this failure.
The sizetopopup attribute is never meant to be set dynamically;
the fix here does not allow us to do so.
Differential Revision: https://phabricator.services.mozilla.com/D16410
--HG--
extra : moz-landing-system : lando