This is not very "clean," and is mostly done in the same sloppy way as Emilio did it because that's basically the only way you can do it. Note well that this does NOT actually turn off everything I've done in a clean fashion like ifdefs would. For instance, the Explicitly Enabled flag is still present, but is now always false because the only condition that can set it true is behind the pref and therefore inert when this pref is off. Also, because the arguments of SetDisabled have changed, my modifications to SetMozDisabled must be present regardless of whether the pref is on or off. What I have done is turn off the actual reflection of the disabled attribute in Disabled and SetDisabled, as well as in AfterSetAttr.
However, turning the pref off seems to restore more or less our old behavior, though there may be subtle differences unlike with an ifdef since this is, unfortunately, not an exact science and I can only turn off changes that happen within individual functions and not changes in how functions interact with each other.
This part of the bug was significantly complicated by the following major refactors:
https://bugzilla.mozilla.org/show_bug.cgi?id=1456435https://bugzilla.mozilla.org/show_bug.cgi?id=1459498
As best as I can tell, we just need to implement the explicitly enabled
flag on every instance of GetStyleSheetInfo, make sure
aIsExplicitlyEnabled is false in every situation except the one where
the disabled content attribute is removed from a link element, and
enable alternate stylesheets if this flag is set on them. So we take the
explicitly enabled flag as an input to PrepareSheet, and also add it to
LoadStyleLink and LoadInlineStyle. I also decided not to defer loading of
alternate stylesheets that have been explicitly enabled.
So basically, I'm trying to adapt this to UXP:
https://bugzilla.mozilla.org/show_bug.cgi?id=1281135
The earliest source of difficulty while adapting Bug 1281135 to our codebase was simply getting the new ErrorResult flag added to the SetDisabled function to play nice with the SetMozDisabled function. At this point, the implementation can actually have a stylesheet be disabled by default but there are supposedly issues with alternate stylesheets.
At first I played around with the return type of SetMozDisabled to no avail, but I found another solution fairly quickly.
https://bugzilla.mozilla.org/show_bug.cgi?id=846972https://bugzilla.mozilla.org/show_bug.cgi?id=1157898
Essentially, the way around the problem of the number of return arguments not matching up is to declare a local variable within SetMozDisabled called ErrorResult rv, and using that to store the return value of the ErrorResult argument from SetDisabled. After that, because ErrorCode was removed, you would return rv.StealNSResult() in order to report success or failure to any consumer that calls on SetMozDisabled.
This is apparently used for fallback selection and if available it is "assumed"
Shadow DOM is also available, while this is a utility function.
Webcompat is a nightmare sometimes.
The added debug assertion did not take into account microtask refactoring done in BZ 1405821.
Resulting in error: no member named 'IsInMicroTask' in 'nsContentUtils'.
This resolves the error.
This splits ScriptLoader up the same way Mozilla did with the exception of
ScriptRequest due to the fact that ScriptLoader and ScriptRequest are
interdependent and would create a circular dependency if split apart when not
using unified building.
Dynamic script loading/unloading (thank you modules) can yank the script
out from under us before the JS API for it is initialized, leading to
null deref crashes.
This adds a simple check if the passed-in object is sane and present.
Resolves#1602
Although the headers were removed, they are still referenced in WebIDL causing compiler to fail for debug builds.
This removes TestFunctions.webidl and TestInterfaceJSMaplikeSetlikeIterable.webidl, with nit fix for existing incorrect whitespace.
This removes the (default disabled) node.rootNode readonly attribute
and replaces it with a node.getRootNode() function per WhatWG
spec discussion.
Based on work by John Dai <jdai@mozilla.com>
This is entangled with the IPC messaging configuration so
we need these IPDLs even if sppech synthesis is otherwise
not being built.
This resolves#1560
