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
Also adds a legacy `GetSameProcessOpener()` method for callers which can only
deal with in-process windows and may need to be updated for Fission.
Differential Revision: https://phabricator.services.mozilla.com/D43692
Also adds a legacy `GetSameProcessOpener()` method for callers which can only
deal with in-process windows and may need to be updated for Fission.
Differential Revision: https://phabricator.services.mozilla.com/D43692
We already allow HTTPS origins to use to plain HTTP active content when using
loopback URLs such as http://127.0.0.1. Lets extend this to WebSocket
connections as well to match Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D38290
I think the root cause of the crash is that WebSocketImpl is not deleted on the target thread. When this happens, there is a race between setting WebSocket::mImpl to nullptr and accessubg mImpl.
If WebSocketImpl is always deleted on the target thread, WebSocketImpl::Disconnect should be called in ~WebSocketImpl when mDisconnectingOrDisconnected is false.
So, this patch checks the ref counter in WebSocketImpl::Release and make sure to delete WebSocketImpl on the right thread.
Differential Revision: https://phabricator.services.mozilla.com/D34320
I think the root cause of the crash is that WebSocketImpl is not deleted on the target thread. When this happens, there is a race between setting WebSocket::mImpl to nullptr and accessubg mImpl.
If WebSocketImpl is always deleted on the target thread, WebSocketImpl::Disconnect should be called in ~WebSocketImpl when mDisconnectingOrDisconnected is false.
So, this patch checks the ref counter in WebSocketImpl::Release and make sure to delete WebSocketImpl on the right thread.
Differential Revision: https://phabricator.services.mozilla.com/D34320
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
