CLOSED TREE
Backed out changeset e716d9ac93d7 (bug 1214148)
Backed out changeset 5f693237c8c1 (bug 1214148)
Backed out changeset 3a4865d79416 (bug 1214148)
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
As discussed on dev-webapi[1] the app that wants to use widgets only
need the "embed-widgets" permission to use <iframe mozbrowser mozwidget>
If the app also wants to implement a browser, it could request the
"browser" separately. A <iframe mozbrowser mozwidget> will have
restricted mozbrowser API defined on the prototype if the embedder has
the "brower" permission; they will always throw when used.
[1]: https://groups.google.com/d/msg/mozilla.dev.webapi/uQweGWtVKRA/Bj1jZq3LN-0J
--HG--
rename : dom/apps/tests/test_widget.html => dom/apps/tests/test_widget_browser.html
As discussed on dev-webapi[1] the app that wants to use widgets only
need the "embed-widgets" permission to use <iframe mozbrowser mozwidget>
If the app also wants to implement a browser, it could request the
"browser" separately. A <iframe mozbrowser mozwidget> will have
restricted mozbrowser API defined on the prototype if the embedder has
the "brower" permission; they will always throw when used.
[1]: https://groups.google.com/d/msg/mozilla.dev.webapi/uQweGWtVKRA/Bj1jZq3LN-0J
As discussed on dev-webapi[1] the app that wants to use widgets only
need the "embed-widgets" permission to use <iframe mozbrowser mozwidget>
If the app also wants to implement a browser, it could request the
"browser" separately. A <iframe mozbrowser mozwidget> will have
restricted mozbrowser API defined on the prototype if the embedder has
the "brower" permission; they will always throw when used.
[1]: https://groups.google.com/d/msg/mozilla.dev.webapi/uQweGWtVKRA/Bj1jZq3LN-0J
