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
It's already possible to get mute/volume at the audio channel level, but
this adds it at the iframe level so that audio channels can be created
and destroyed and the setting will be preserved.
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
--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
--HG--
rename : dom/apps/tests/test_widget.html => dom/apps/tests/test_widget_browser.html
