MozDOMFullscreen:{Request,Exit} are simply used to redirect the request
to the parent process, hence there is no need to align them with refresh
driver tick or dispatch asynchronously.
MozDOMFullscreen:{Entered,Exited} are also used to notify the content
process about the change, hence dispatching them later could cause
unwanted delay on fullscreen change. Their handlers are also changed in
this patch to avoid recursive fullscreen change.
This change splits PLDHashTable::Iterator::NextEntry() into two separate
functions, which allow you to get the current element and advance the iterator
separately, which means you can use a for-loop to iterate instead of a
while-loop.
As part of this change, the internals of PLDHashTable::Iterator were
significantly changed and simplified (and modelled after js::HashTable's
equivalent code). It's no longer duplicating code from PL_DHashTableEnumerator.
The chaos mode code was a casualty of this, but given how unreliable that code
has proven to be (see bug 1173212, bug 1174046) this is for the best. (We can
reimplement chaos mode once PLDHashTable::Iterator is back on more solid
footing again, if we think it's important.)
All these changes will make it much easier to add an alternative Iterator that
removes elements, which was turning out to be difficult with the prior code.
In order to make the for-loop header usually fit on a single line, I
deliberately renamed a bunch of things to have shorter names.
In summary, you used to write this:
PLDHashTable::Iterator iter(&table);
while (iter.HasMoreEntries()) {
auto entry = static_cast<FooEntry*>(iter.NextEntry());
// ... do stuff with |entry| ...
}
// iter's scope extends beyond here
and now you write this:
for (auto iter = table.Iter(); !iter.Done(); iter.Next()) {
auto entry = static_cast<FooEntry*>(iter.Get());
// ... do stuff with |entry| ...
}
// iter's scope doesn't reach here
This is straightforward mapping of PR_LOG levels to their LogLevel
counterparts:
PR_LOG_ERROR -> LogLevel::Error
PR_LOG_WARNING -> LogLevel::Warning
PR_LOG_WARN -> LogLevel::Warning
PR_LOG_INFO -> LogLevel::Info
PR_LOG_DEBUG -> LogLevel::Debug
PR_LOG_NOTICE -> LogLevel::Debug
PR_LOG_VERBOSE -> LogLevel::Verbose
Instances of PRLogModuleLevel were mapped to a fully qualified
mozilla::LogLevel, instances of PR_LOG levels in #defines were mapped to a
fully qualified mozilla::LogLevel::* level, and all other instances were
mapped to us a shorter format of LogLevel::*.
Bustage for usage of the non-fully qualified LogLevel were fixed by adding
|using mozilla::LogLevel;| where appropriate.
This is straightforward mapping of PR_LOG levels to their LogLevel
counterparts:
PR_LOG_ERROR -> LogLevel::Error
PR_LOG_WARNING -> LogLevel::Warning
PR_LOG_WARN -> LogLevel::Warning
PR_LOG_INFO -> LogLevel::Info
PR_LOG_DEBUG -> LogLevel::Debug
PR_LOG_NOTICE -> LogLevel::Debug
PR_LOG_VERBOSE -> LogLevel::Verbose
Instances of PRLogModuleLevel were mapped to a fully qualified
mozilla::LogLevel, instances of PR_LOG levels in #defines were mapped to a
fully qualified mozilla::LogLevel::* level, and all other instances were
mapped to us a shorter format of LogLevel::*.
Bustage for usage of the non-fully qualified LogLevel were fixed by adding
|using mozilla::LogLevel;| where appropriate.
This is straightforward mapping of PR_LOG levels to their LogLevel
counterparts:
PR_LOG_ERROR -> LogLevel::Error
PR_LOG_WARNING -> LogLevel::Warning
PR_LOG_WARN -> LogLevel::Warning
PR_LOG_INFO -> LogLevel::Info
PR_LOG_DEBUG -> LogLevel::Debug
PR_LOG_NOTICE -> LogLevel::Debug
PR_LOG_VERBOSE -> LogLevel::Verbose
Instances of PRLogModuleLevel were mapped to a fully qualified
mozilla::LogLevel, instances of PR_LOG levels in #defines were mapped to a
fully qualified mozilla::LogLevel::* level, and all other instances were
mapped to us a shorter format of LogLevel::*.
Bustage for usage of the non-fully qualified LogLevel were fixed by adding
|using mozilla::LogLevel;| where appropriate.
This patch renames DispatchChromeOnly flag to OnlyChromeDispatch. With
this patch, if OnlyChromeDispatch flag is set, and the target is already
a chrome node, the dispatch path will start from the target. Previously,
even if the target is a chrome node, the dispatch path starts from the
parent target of the owner window of the current node.
