Timeline

Sep 11, 2016:

11:54 PM Changeset in webkit [205795] by bshafiei@apple.com

• 5 edits in branches/safari-602-branch/Source

Versioning.

9:03 PM Changeset in webkit [205794] by fpizlo@apple.com

• 17 edits
  1 delete in trunk/Source

FastBitVector should have efficient and easy-to-use vector-vector operations
​https://bugs.webkit.org/show_bug.cgi?id=161847

Reviewed by Saam Barati.

Source/JavaScriptCore:

Adapt existing users of FastBitVector to the new API.

• bytecode/BytecodeLivenessAnalysis.cpp:

(JSC::BytecodeLivenessAnalysis::computeKills):
(JSC::BytecodeLivenessAnalysis::dumpResults):

• bytecode/BytecodeLivenessAnalysisInlines.h:

(JSC::operandThatIsNotAlwaysLiveIsLive):
(JSC::BytecodeLivenessPropagation<DerivedAnalysis>::stepOverInstruction):
(JSC::BytecodeLivenessPropagation<DerivedAnalysis>::runLivenessFixpoint):

• bytecode/CodeBlock.cpp:

(JSC::CodeBlock::validate):

• dfg/DFGByteCodeParser.cpp:

(JSC::DFG::ByteCodeParser::flushForTerminal):

• dfg/DFGForAllKills.h:

(JSC::DFG::forAllKilledOperands):

• dfg/DFGGraph.h:

(JSC::DFG::Graph::forAllLocalsLiveInBytecode):

• dfg/DFGLiveCatchVariablePreservationPhase.cpp:

(JSC::DFG::LiveCatchVariablePreservationPhase::willCatchException):
(JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock):

• dfg/DFGNaturalLoops.cpp:

(JSC::DFG::NaturalLoops::NaturalLoops):

• dfg/DFGPlan.cpp:

(JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):

Source/WTF:

FastBitVector is a bitvector representation that supports manual dynamic resizing and is
optimized for speed, not space. (BitVector supports automatic dynamic resizing and is
optimized for space, while Bitmap is sized statically and is optimized for both speed and
space.) This change greatly increases the power of FastBitVector. We will use these new
powers for changing the JSC GC to use FastBitVectors to track sets of MarkedBlocks (bug
161581) instead of using a combination of Vectors and doubly-linked lists.

This change splits FastBitVector into two parts:

• A thing that manages the storage of a bitvector: a uint32_t array and a size_t numBits. We call this the word view.
• A thing that takes some kind of abstract array of uint32_t's and does bitvector operations to it. We call this the FastBitVectorImpl.

FastBitVectorImpl and word views are immutable. The FastBitVector class is a subclass of
FastBitVectorImpl specialized on a word view that owns its words and has additional
support for mutable operations.

Doing this allows us to efficiently support things like this without any unnecessary
memory allocation or copying:

FastBitVector a, b, c; Assume that there is code to initialize these.
a &= b | ~c;

Previously, this kind of operation would not be efficient, because "~c" would have to
create a whole new FastBitVector. But now, it just returns a FastBitVectorImpl whose
underlying word view bitnots (~) its words on the fly. Using template magic, this can get
pretty complex. For example "b | ~c" returns a FastBitVectorImpl that wraps a word view
whose implementation of WordView::word(size_t index) is something like:

uint32_t word(size_t index) { return b.m_words.word(index) | ~c.m_words.word(index); }

FastBitVectorImpl supports all of the fast bulk bitvector operations, like
forEachSetBit(), bitCount(), etc. So, when you say "a &= b | ~c", the actual
implementation is going to run these bit operations on word granularity directly over the
storage inside a, b, c.

The use of operator overloading is worth explaining a bit. Previously, FastBitVector
avoided operator overloading. For example, the &= operation was called filter(). I think
that this was a pretty good approach at the time. I tried using non-operator methods in
this FastBitVector rewrite, but I found it very odd to say things like:

a.filter(b.bitOr(c.bitNot()));

I think that it's harder to see what is going on here, then using operators, because infix
notation is always better.

• WTF.xcodeproj/project.pbxproj:
• wtf/BitVector.h:

(WTF::BitVector::findBitInWord): Deleted.

• wtf/CMakeLists.txt:
• wtf/Dominators.h:

(WTF::Dominators::NaiveDominators::NaiveDominators):
(WTF::Dominators::NaiveDominators::dominates):
(WTF::Dominators::NaiveDominators::pruneDominators):

• wtf/FastBitVector.cpp: Removed.
• wtf/FastBitVector.h:

(WTF::fastBitVectorArrayLength):
(WTF::FastBitVectorWordView::FastBitVectorWordView):
(WTF::FastBitVectorWordView::numBits):
(WTF::FastBitVectorWordView::word):
(WTF::FastBitVectorWordOwner::FastBitVectorWordOwner):
(WTF::FastBitVectorWordOwner::~FastBitVectorWordOwner):
(WTF::FastBitVectorWordOwner::view):
(WTF::FastBitVectorWordOwner::operator=):
(WTF::FastBitVectorWordOwner::setAll):
(WTF::FastBitVectorWordOwner::clearAll):
(WTF::FastBitVectorWordOwner::set):
(WTF::FastBitVectorWordOwner::numBits):
(WTF::FastBitVectorWordOwner::arrayLength):
(WTF::FastBitVectorWordOwner::resize):
(WTF::FastBitVectorWordOwner::word):
(WTF::FastBitVectorWordOwner::words):
(WTF::FastBitVectorAndWords::FastBitVectorAndWords):
(WTF::FastBitVectorAndWords::view):
(WTF::FastBitVectorAndWords::numBits):
(WTF::FastBitVectorAndWords::word):
(WTF::FastBitVectorOrWords::FastBitVectorOrWords):
(WTF::FastBitVectorOrWords::view):
(WTF::FastBitVectorOrWords::numBits):
(WTF::FastBitVectorOrWords::word):
(WTF::FastBitVectorNotWords::FastBitVectorNotWords):
(WTF::FastBitVectorNotWords::view):
(WTF::FastBitVectorNotWords::numBits):
(WTF::FastBitVectorNotWords::word):
(WTF::FastBitVectorImpl::FastBitVectorImpl):
(WTF::FastBitVectorImpl::numBits):
(WTF::FastBitVectorImpl::size):
(WTF::FastBitVectorImpl::arrayLength):
(WTF::FastBitVectorImpl::operator==):
(WTF::FastBitVectorImpl::operator!=):
(WTF::FastBitVectorImpl::at):
(WTF::FastBitVectorImpl::operator[]):
(WTF::FastBitVectorImpl::bitCount):
(WTF::FastBitVectorImpl::operator&):
(WTF::FastBitVectorImpl::operator|):
(WTF::FastBitVectorImpl::operator~):
(WTF::FastBitVectorImpl::forEachSetBit):
(WTF::FastBitVectorImpl::forEachClearBit):
(WTF::FastBitVectorImpl::forEachBit):
(WTF::FastBitVectorImpl::findBit):
(WTF::FastBitVectorImpl::findSetBit):
(WTF::FastBitVectorImpl::findClearBit):
(WTF::FastBitVectorImpl::dump):
(WTF::FastBitVectorImpl::atImpl):
(WTF::FastBitVector::FastBitVector):
(WTF::FastBitVector::operator=):
(WTF::FastBitVector::resize):
(WTF::FastBitVector::setAll):
(WTF::FastBitVector::clearAll):
(WTF::FastBitVector::setAndCheck):
(WTF::FastBitVector::operator|=):
(WTF::FastBitVector::operator&=):
(WTF::FastBitVector::at):
(WTF::FastBitVector::operator[]):
(WTF::FastBitVector::BitReference::BitReference):
(WTF::FastBitVector::BitReference::operator bool):
(WTF::FastBitVector::BitReference::operator=):
(WTF::FastBitVector::~FastBitVector): Deleted.
(WTF::FastBitVector::numBits): Deleted.
(WTF::FastBitVector::set): Deleted.
(WTF::FastBitVector::equals): Deleted.
(WTF::FastBitVector::merge): Deleted.
(WTF::FastBitVector::filter): Deleted.
(WTF::FastBitVector::exclude): Deleted.
(WTF::FastBitVector::clear): Deleted.
(WTF::FastBitVector::get): Deleted.
(WTF::FastBitVector::bitCount): Deleted.
(WTF::FastBitVector::forEachSetBit): Deleted.
(WTF::FastBitVector::arrayLength): Deleted.

• wtf/StdLibExtras.h:

(WTF::findBitInWord):

8:29 PM Changeset in webkit [205793] by commit-queue@webkit.org

• 2 edits
  4 adds
  14 deletes in trunk/Source/WebInspectorUI

Web Inspector: Combine similar SVG files for Styles sidebar
​https://bugs.webkit.org/show_bug.cgi?id=161071

Patch by Devin Rousso <Devin Rousso> on 2016-09-11
Reviewed by Joseph Pecoraro.

• UserInterface/Images/StyleRule.svg: Added.
• UserInterface/Images/StyleRulePseudoElement.svg: Added.

Replaced <defs> with <symbol> give CSS some access to the referenced DOM inside <symbol>.
Since <symbol> uses Shadow DOM, applying CSS variables to the :target element and using
them inside <symbol> allows for variable styling of the content. Using a more basic
#foo .bar selector would not be valid since Shadow DOM separates the stylesheet selectors.

• UserInterface/Images/gtk/StyleRule.svg: Added.
• UserInterface/Images/gtk/StyleRulePseudoElement.svg: Added.

• UserInterface/Images/StyleRuleAuthor.svg: Removed.
• UserInterface/Images/StyleRuleInherited.svg: Removed.
• UserInterface/Images/StyleRuleInspector.svg: Removed.
• UserInterface/Images/StyleRuleUser.svg: Removed.
• UserInterface/Images/StyleRuleUserAgent.svg: Removed.
• UserInterface/Images/gtk/StyleRuleAuthor.svg: Removed.
• UserInterface/Images/gtk/StyleRuleInherited.svg: Removed.
• UserInterface/Images/gtk/StyleRuleInspector.svg: Removed.
• UserInterface/Images/gtk/StyleRuleUser.svg: Removed.
• UserInterface/Images/gtk/StyleRuleUserAgent.svg: Removed.

Merged into StyleRule.svg by using IDs in the URL.

• UserInterface/Images/StyleRuleAuthorPseudo.svg: Removed.
• UserInterface/Images/StyleRuleInspectorPseudo.svg: Removed.
• UserInterface/Images/StyleRuleUserAgentPseudo.svg: Removed.
• UserInterface/Images/StyleRuleUserPseudo.svg: Removed.

Merged into StyleRulePseudoElement.svg by using IDs in the URL.

• UserInterface/Views/StyleRuleIcons.css:

(.author-style-rule-icon .icon):
(.author-style-rule-icon.pseudo-element-selector .icon):
(.user-style-rule-icon .icon):
(.user-style-rule-icon.pseudo-element-selector .icon):
(.user-agent-style-rule-icon .icon):
(.user-agent-style-rule-icon.pseudo-element-selector .icon):
(.inspector-style-rule-icon .icon):
(.inspector-style-rule-icon.pseudo-element-selector .icon):
(.inherited-style-rule-icon .icon):

5:03 PM Changeset in webkit [205792] by commit-queue@webkit.org

• 3 edits in trunk/Source/WebInspectorUI

REGRESSION (r205754): Web Inspector: Cannot click on links to stylesheets in Rules sidebar
​https://bugs.webkit.org/show_bug.cgi?id=161838

Patch by Devin Rousso <Devin Rousso> on 2016-09-11
Reviewed by Brian Burg.

• UserInterface/Views/CSSStyleDeclarationSection.css:

(.style-declaration-section > .header > textarea):
(.style-declaration-section > .header > .origin):
Added z-index to the non-selector elements of the header. Also limited the size of the
selector textarea to just the size of the displayed selector text.

• UserInterface/Views/CSSStyleDeclarationTextEditor.js:

(WebInspector.CSSStyleDeclarationTextEditor):
Fixed invalid enum value for propertyVisibilityMode.

3:30 PM Changeset in webkit [205791] by Chris Dumez

• 11 edits in trunk

HTMLTrackElement.kind's invalid value default should be the metadata state
​https://bugs.webkit.org/show_bug.cgi?id=161840

Reviewed by Eric Carlson.

LayoutTests/imported/w3c:

Rebaseline existing tests now that more checks are passing.

• web-platform-tests/html/dom/reflection-embedded-expected.txt:
• web-platform-tests/html/semantics/embedded-content/media-elements/interfaces/HTMLElement/HTMLTrackElement/kind-expected.txt:
• web-platform-tests/html/semantics/embedded-content/media-elements/interfaces/TextTrack/kind-expected.txt:

Source/WebCore:

HTMLTrackElement.kind's invalid value default should be the metadata state,
not the subtitles state:

• ​https://html.spec.whatwg.org/#attr-track-kind

Chrome agrees with the specification.

No new tests, rebaselined existing tests.

• html/track/TextTrack.cpp:

(WebCore::TextTrack::setKindKeywordIgnoringASCIICase):

LayoutTests:

• media/track/track-kind-expected.txt:
• media/track/track-kind.html:

Update existing test to reflect behavior change.

• media/track/w3c/interfaces/TextTrack/kind.html:

Re-sync test from W3C as it was outdated.

11:11 AM Changeset in webkit [205790] by hyatt@apple.com

• 11 edits
  4 adds in trunk/Source/WebCore

[CSS Parser] Add the main parser implementation
​https://bugs.webkit.org/show_bug.cgi?id=161813

Reviewed by Dean Jackson.

This patch adds the main CSSParserImpl that handles stylesheet and rule parsing. All parsing starts with this
class (it will eventually be invoked from the CSSParser). This patch also adds @supports parsing.

• WebCore.xcodeproj/project.pbxproj:
• css/CSSKeyframeRule.cpp:

(WebCore::StyleKeyframe::StyleKeyframe):

• css/CSSKeyframeRule.h:
• css/StyleRule.cpp:

(WebCore::StyleRuleBase::destroy):
(WebCore::StyleRuleBase::copy):
(WebCore::StyleRuleBase::createCSSOMWrapper):
(WebCore::StyleRuleCharset::StyleRuleCharset):
(WebCore::StyleRuleCharset::~StyleRuleCharset):
(WebCore::StyleRuleNamespace::StyleRuleNamespace):
(WebCore::StyleRuleNamespace::~StyleRuleNamespace):

• css/StyleRule.h:

(WebCore::StyleRuleBase::isNamespaceRule):
(isType):
(WebCore::StyleRuleBase::isKeyframesRule): Deleted.

• css/StyleSheetContents.cpp:

(WebCore::traverseSubresourcesInRules):

• css/parser/CSSParserImpl.cpp: Added.

(WebCore::CSSParserImpl::CSSParserImpl):
(WebCore::CSSParserImpl::parseValue):
(WebCore::CSSParserImpl::parseVariableValue):
(WebCore::filterProperties):
(WebCore::createStyleProperties):
(WebCore::CSSParserImpl::parseInlineStyleDeclaration):
(WebCore::CSSParserImpl::parseDeclarationList):
(WebCore::CSSParserImpl::parseRule):
(WebCore::CSSParserImpl::parseStyleSheet):
(WebCore::CSSParserImpl::parsePageSelector):
(WebCore::CSSParserImpl::parseCustomPropertySet):
(WebCore::CSSParserImpl::parseKeyframeKeyList):
(WebCore::CSSParserImpl::supportsDeclaration):
(WebCore::CSSParserImpl::parseDeclarationListForInspector):
(WebCore::CSSParserImpl::parseStyleSheetForInspector):
(WebCore::computeNewAllowedRules):
(WebCore::CSSParserImpl::consumeRuleList):
(WebCore::CSSParserImpl::consumeAtRule):
(WebCore::CSSParserImpl::consumeQualifiedRule):
(WebCore::consumeStringOrURI):
(WebCore::CSSParserImpl::consumeCharsetRule):
(WebCore::CSSParserImpl::consumeImportRule):
(WebCore::CSSParserImpl::consumeNamespaceRule):
(WebCore::CSSParserImpl::consumeMediaRule):
(WebCore::CSSParserImpl::consumeSupportsRule):
(WebCore::CSSParserImpl::consumeViewportRule):
(WebCore::CSSParserImpl::consumeFontFaceRule):
(WebCore::CSSParserImpl::consumeKeyframesRule):
(WebCore::CSSParserImpl::consumePageRule):
(WebCore::CSSParserImpl::consumeKeyframeStyleRule):
(WebCore::observeSelectors):
(WebCore::CSSParserImpl::consumeStyleRule):
(WebCore::CSSParserImpl::consumeDeclarationList):
(WebCore::CSSParserImpl::consumeDeclaration):
(WebCore::CSSParserImpl::consumeVariableValue):
(WebCore::CSSParserImpl::consumeDeclarationValue):
(WebCore::CSSParserImpl::consumeKeyframeKeyList):

• css/parser/CSSParserImpl.h: Added.
• css/parser/CSSParserValues.cpp:

(WebCore::CSSParserSelector::parsePagePseudoSelector):

• css/parser/CSSParserValues.h:
• css/parser/CSSPropertyParser.cpp:

(WebCore::CSSPropertyParser::parseValue):

• css/parser/CSSSupportsParser.cpp: Added.

(WebCore::CSSSupportsParser::supportsCondition):
(WebCore::CSSSupportsParser::consumeCondition):
(WebCore::CSSSupportsParser::consumeNegation):
(WebCore::CSSSupportsParser::consumeConditionInParenthesis):

• css/parser/CSSSupportsParser.h: Added.

(WebCore::CSSSupportsParser::CSSSupportsParser):

7:10 AM Changeset in webkit [205789] by Gyuyoung Kim

• 2 edits in trunk/LayoutTests

[EFL] Skip to test some w3c/web-platform-tests

Unreviewed EFL gardening.

Some tests of w3c/web-platform-tests have been flaky since r205777.

• platform/efl/TestExpectations

12:24 AM Changeset in webkit [205788] by timothy_horton@apple.com

• 9 edits
  4 adds in trunk

Candidates that don't end in spaces shouldn't have spaces arbitrarily appended to them
​https://bugs.webkit.org/show_bug.cgi?id=161846
<rdar://problem/28245097>

Reviewed by Beth Dakin.

Tests: editing/mac/spelling/accept-candidate-without-adding-space.html,

editing/mac/spelling/accept-candidate-allows-autocorrect-on-next-word.html

• editing/Editor.cpp:

(WebCore::Editor::handleAcceptedCandidate):
Stop appending a space just because the candidate doesn't end in a space.
There are languages where that doesn't make sense, and the platform
guarantees that candidates will always have spaces if they need them.

Also, adjust the way we compute the AcceptedCandidate document marker range.
There were two problems with the existing code: it expanded outward from
the post-insertion cursor in *both* directions, instead of just backwards,
and it used the length of the replaced text, not the length of the newly
inserted text (more of the confusion mentioned in r205765).

• editing/mac/spelling/accept-candidate-replacing-multiple-words-expected.txt:
• editing/mac/spelling/accept-candidate-replacing-multiple-words.html:
• editing/mac/spelling/accept-candidate-without-crossing-editing-boundary-expected.txt:
• editing/mac/spelling/accept-candidate-without-crossing-editing-boundary.html:

Update existing tests to put spaces at the end of accepted candidates to make them
more similar to what the OS will return to us.

• editing/mac/spelling/accept-candidate-without-adding-space-expected.txt: Added.
• editing/mac/spelling/accept-candidate-without-adding-space.html: Added.

Add a test where the accepted candidate does *not* have a space at the end,
testing that we don't add one where the candidate didn't contain one.

• editing/mac/spelling/accept-candidate-allows-autocorrect-on-next-word-expected.txt: Added.
• editing/mac/spelling/accept-candidate-allows-autocorrect-on-next-word.html: Added.

Add a test ensuring that the document marker added by accepting a candidate
doesn't overlap the next word and prevent autocorrect from working on it.

Sep 10, 2016:

11:08 AM Changeset in webkit [205787] by Chris Dumez

• 18 edits in trunk

parseHTMLInteger() should take a StringView in parameter
​https://bugs.webkit.org/show_bug.cgi?id=161669

Reviewed by Ryosuke Niwa.

Source/JavaScriptCore:

• runtime/DateConversion.cpp:

(JSC::formatDateTime):
Explicitly construct a String from the const WCHAR* on Windows because
it is ambiguous otherwise now that there is a StringBuilder::append()
overload taking an AtomicString in.

Source/WebCore:

parseHTMLInteger() should take a StringView in parameter instead of a
const String&.

• css/parser/CSSParser.cpp:

(WebCore::CSSParser::parseFontFaceSrcLocal):

• css/parser/CSSParserValues.h:

(WebCore::CSSParserString::toStringView):
Add toStringView() to avoid unnecessarily constructing a String for
calling StringBuilder::append().

• html/parser/HTMLParserIdioms.cpp:

(WebCore::parseHTMLInteger):
(WebCore::parseHTMLNonNegativeInteger):
(WebCore::parseHTTPRefreshInternal):

• html/parser/HTMLParserIdioms.h:

(WebCore::limitToOnlyHTMLNonNegativeNumbersGreaterThanZero):
(WebCore::limitToOnlyHTMLNonNegative):
Take a StringView in parameter instead of a const String&.

• platform/sql/SQLiteStatement.cpp:

(WebCore::SQLiteStatement::isColumnDeclaredAsBlob):
Avoid unnecessarily constructing a String to call equalLettersIgnoringASCIICase()
by leveraging the StringView constructor taking a 'const char*' in parameter.

• rendering/RenderBlock.cpp:

(WebCore::RenderBlock::constructTextRun):

• rendering/RenderBlock.h:

Add constructTextRun() overload taking an AtomicString. It was otherwise ambiguous
because both a String or a StringView could be constructed from an AtomicString.

• page/CaptionUserPreferencesMediaAF.cpp:

(WebCore::CaptionUserPreferencesMediaAF::captionsDefaultFontCSS):
(WebCore::buildDisplayStringForTrackBase):

• rendering/RenderThemeMac.mm:

(WebCore::RenderThemeMac::mediaControlsStyleSheet):
(WebCore::RenderThemeMac::mediaControlsScript):
Explicitly construct a String from NSString / CFStringRef types as such calls are
now ambiguous.

Source/WTF:

• wtf/text/StringBuilder.h:

(WTF::StringBuilder::append):
Add StringBuilder::append() overload taking an AtomicString in parameter.
It used to call StringBuilder::append(const String&) implicitly when
passing an AtomicString. However, it is now ambiguous because there
is an overload taking a StringView, and it is now possible to construct
a StringView from an AtomicString.

• wtf/text/StringView.h:

(WTF::StringView::StringView):

• Add StringView constructor taking an AtomicString in parameter for convenience. This avoids having to call AtomicString::string() explicitly at call sites.
• Add StringView constructor taking a 'const char*' in parameter for performance. There are several call sites that were passing a const char* and implicitly constructing an unnecessary String to construct a StringView. This became more obvious because the constructor taking an AtomicString in parameter made such calls ambiguous.

Tools:

Explicitly construct a String from the CFStringRef in order to call
StringBuilder::append(). This is needed now that there is an append()
overload taking an AtomicString in parameter.

• WebKitTestRunner/InjectedBundle/InjectedBundlePage.cpp:

(WTR::InjectedBundlePage::dumpDOMAsWebArchive):

9:06 AM Changeset in webkit [205786] by Chris Dumez

• 9 edits
  2 adds in trunk

It is possible for Document::m_frame pointer to become stale
​https://bugs.webkit.org/show_bug.cgi?id=161812
<rdar://problem/27745023>

Reviewed by Ryosuke Niwa.

Source/WebCore:

Document::m_frame is supposed to get cleared by Document::prepareForDestruction().
The Frame destructor calls Frame::setView(nullptr) which is supposed to call the
prepareForDestruction() on the Frame's associated document. However,
Frame::setView(nullptr) was calling prepareForDestruction() only if
Document::inPageCache() returned true. This is because, we allow Documents to
stay alive in the PageCache even though they don't have a frame.

The issue is that Document::m_inPageCache flag was set to true right before
firing the pagehide event, so technically before really entering PageCache.
Therefore, we can run into problems if a Frame gets destroyed by a pagehide
EventHandler because ~Frame() will not call Document::prepareForDestruction()
due to Document::m_inPageCache being true. After the frame is destroyed,
Document::m_frame becomes stale and any action on the document will likely
lead to crashes (such as the one in the layout test and the radar which
happens when trying to unregister event listeners from the document).

The solution adopted in this patch is to replace the m_inPageCache boolean
with a m_pageCacheState enumeration that has 3 states:

• NotInPageCache
• AboutToEnterPageCache
• InPageCache

Frame::setView() / Frame::setDocument() were then updated to call
Document::prepareForDestruction() on the associated document whenever
the document's pageCacheState is not InPageCache. This means that we
will now call Document::prepareForDestruction() when the document is
being detached from its frame while firing the pagehide event.

Note that I tried to keep this patch minimal. Therefore, I kept
the Document::inPageCache() getter for now. I plan to switch all its
calls sites to the new Document::pageCacheState() getter in a follow-up
patch so that we can finally drop the confusing Document::inPageCache().

Test: fast/history/pagehide-remove-iframe-crash.html

• dom/Document.cpp:

(WebCore::Document::Document):
(WebCore::Document::~Document):
(WebCore::Document::createRenderTree):
(WebCore::Document::destroyRenderTree):
(WebCore::Document::setFocusedElement):
(WebCore::Document::setPageCacheState):
(WebCore::Document::topDocument):

• dom/Document.h:

(WebCore::Document::pageCacheState):
(WebCore::Document::inPageCache):

• history/CachedFrame.cpp:

(WebCore::CachedFrame::destroy):

• history/PageCache.cpp:

(WebCore::setPageCacheState):
(WebCore::PageCache::addIfCacheable):

• loader/FrameLoader.cpp:

(WebCore::FrameLoader::stopAllLoaders):
(WebCore::FrameLoader::open):

• loader/HistoryController.cpp:

(WebCore::HistoryController::invalidateCurrentItemCachedPage):

• page/Frame.cpp:

(WebCore::Frame::setView):

LayoutTests:

Add layout test that crashes on both Mac and iOS due to using a stale
Document::m_frame pointer.

• fast/history/pagehide-remove-iframe-crash-expected.txt: Added.
• fast/history/pagehide-remove-iframe-crash.html: Added.

8:06 AM Changeset in webkit [205785] by Gyuyoung Kim

• 2 edits in trunk/LayoutTests

[EFL] Mark new media source tests to failure

Unreviewed EFL gardening.

• platform/efl/TestExpectations: New added media source tests are failing.

4:42 AM WebKitGTK/2.14.x edited by Carlos Garcia Campos

(diff)

1:19 AM Changeset in webkit [205784] by Wenson Hsieh

• 7 edits
  1 add in trunk

Apple.com keynote does not display media controls
​https://bugs.webkit.org/show_bug.cgi?id=161833
<rdar://problem/28230123>

Reviewed by Tim Horton.

Source/WebCore:

Tweaks the main content check so that we can distinguish between main content for the purposes of determining
autoplay policy vs. main content for the purposes of showing media controls. Namely, we make the latter less
restrictive than the former in terms of the maximum aspect ratio a video can have to be considered the right
size for main content.

New unit test in TestWebKitAPI.

• html/HTMLMediaElement.cpp:

(WebCore::mediaElementSessionInfoForSession):

• html/MediaElementSession.cpp:

(WebCore::MediaElementSession::canShowControlsManager):
(WebCore::MediaElementSession::isLargeEnoughForMainContent):
(WebCore::MediaElementSession::wantsToObserveViewportVisibilityForMediaControls):
(WebCore::isMainContentForPurposesOfAutoplay):
(WebCore::isElementLargeEnoughForMainContent):
(WebCore::MediaElementSession::updateIsMainContent):
(WebCore::isMainContent): Deleted.

• html/MediaElementSession.h:

Tools:

New unit test verifying that wide videos (~2 aspect ratio) still get media controls.

• TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
• TestWebKitAPI/Tests/WebKit2Cocoa/VideoControlsManager.mm:

(TestWebKitAPI::TEST):

• TestWebKitAPI/Tests/WebKit2Cocoa/wide-autoplaying-video-with-audio.html: Added.