With a very simple tweak to SheetLoadDataHashKey::KeyEquals we should
get the same kind of caching but in a much simpler way.
Depends on D125450
Differential Revision: https://phabricator.services.mozilla.com/D124807
With a very simple tweak to SheetLoadDataHashKey::KeyEquals we should
get the same kind of caching but in a much simpler way.
Differential Revision: https://phabricator.services.mozilla.com/D124807
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
- Add new data member StyleSheet::mParentObject
- Clone Sheets before adding them to nsXULPrototypeCache
- Return mParentObject from GetParentObject if non-null
Differential Revision: https://phabricator.services.mozilla.com/D72725
A logic error is causing nsXULPrototypeCache::HasData to almost always return
true meaning we aren't actually writing anything to the XUL prototype cache.
Differential Revision: https://phabricator.services.mozilla.com/D63602
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
This was generated with:
```
rg -l -g '*.{cpp,h}' MOZ_XBL . | while read FILE ; do
echo $FILE
unifdef -m -UMOZ_XBL $FILE
done
```
After this, I manually removed the directive in nsContentUtils.cpp due to:
unifdef: ./dom/base/nsContentUtils.cpp: 4630: Unterminated string literal
unifdef: Output may be truncated
Differential Revision: https://phabricator.services.mozilla.com/D51337
--HG--
extra : moz-landing-system : lando
When XBL is disabled, no code in dom/xbl will be built. Also, adds ifdefs
to remove any of the XBL related code elsewhere. There's definitely more
that can be done here, but I think it's better to wait to do the rest of
the cleanup when we actually remove the code.
Depends on D45612
Differential Revision: https://phabricator.services.mozilla.com/D45613
--HG--
extra : moz-landing-system : lando
The signatures were updated in the previous patch to hand us the raw,
uncopied buffers. This just adjusts the callsites to match.
Differential Revision: https://phabricator.services.mozilla.com/D34653
--HG--
extra : moz-landing-system : lando
This will not behave exactly the same if we had previously written bad
data for the entry that would fail to decompress. I imagine this is rare
enough, and the consequences are not severe enough, that this should be
fine.
Differential Revision: https://phabricator.services.mozilla.com/D30643
--HG--
extra : moz-landing-system : lando
The signatures were updated in the previous patch to hand us the raw,
uncopied buffers. This just adjusts the callsites to match.
Differential Revision: https://phabricator.services.mozilla.com/D34653
--HG--
extra : moz-landing-system : lando
This will not behave exactly the same if we had previously written bad
data for the entry that would fail to decompress. I imagine this is rare
enough, and the consequences are not severe enough, that this should be
fine.
Differential Revision: https://phabricator.services.mozilla.com/D30643
--HG--
extra : moz-landing-system : lando
Create a new parser (PrototypeDocumentParser) and content sink
(PrototypeDocumentContentSink) that can be used by both XUL and XHTML.
The new parser moves the code from XULDocument that handles creating and
loading a nsXULPrototypeDocument from either the cache or the source
file. Once the parser has finished loading the prototype it notifies the
content sink. The parser is largely a stub and would be better suited
for use as a nsBaseParser, but nsHTMLDocument unfortunately needs an
nsIParser.
The new content sink has the XULDocument code responsible for the
prototype traversal that creates the DOM (XULDocument::ResumeWalk and
friends) and fires off various events.
To unify XUL and XHTML, the XHTML readystate event sequence is used in
XUL. However, the layout path of XHTML loaded from the prototype cache
more closely follows XUL, where frame initializers and layout don't
start until the entire DOM is built.
Differential Revision: https://phabricator.services.mozilla.com/D21236
--HG--
rename : dom/xul/XULDocument.cpp => dom/prototype/PrototypeDocumentContentSink.cpp
rename : parser/moz.build => dom/prototype/moz.build
rename : parser/moz.build => parser/prototype/moz.build
extra : moz-landing-system : lando