Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Seamless #2

Merged
merged 8 commits into from Apr 12, 2012
Merged

Seamless #2

merged 8 commits into from Apr 12, 2012

Conversation

abarth
Copy link

@abarth abarth commented Apr 11, 2012

Here's a first cut at the seamless navigation code. I'm having troubling running the tests, so it's a bit tricky to say whether this code works yet. :)

@eseidel eseidel merged this pull request into eseidel:seamless Apr 12, 2012
eseidel pushed a commit that referenced this pull request Apr 15, 2012
* platform/gtk/test_expectations.txt:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@113995 268f45cc-cd09-0410-ab3c-d52691b4dbfc
eseidel pushed a commit that referenced this pull request Aug 28, 2012
https://bugs.webkit.org/show_bug.cgi?id=94740

Patch by Sukolsak Sakshuwong <sukolsak@gmail.com> on 2012-08-28
Reviewed by Ryosuke Niwa.

Source/WebCore:

This bug happened when we selected "1<progress><a style>2</a></progress>"
and executed a create link command because

1. The selection ended at <progress>, not the text node inside it, because
   <progress> is an atomic node.
2. We called removeInlineStyle() to remove conflicting styles.
   Since the selection started at the text node "1" and ended at <progress>,
   we did not get to remove <a>.
3. We called fixRangeAndApplyInlineStyle(), which in turn called
   applyInlineStyleToNodeRange(). This method split the node range
   into smaller runs. In this case, the run was the whole
   "1<progress><a style>2</a></progress>".
4. We called removeStyleFromRunBeforeApplyingStyle(). This method tried
   to remove <a> by calling removeInlineStyleFromElement() on <a> with
   extractedStyle = 0. But the method expected that extractedStyle was not null.
   So, it crashed.

This bug doesn't happen with non-atomic nodes because if <a> is inside a non-atomic
node, <a> will be covered by the selection. Therefore, it will be removed in
step #2 and we will never call removeInlineStyleFromElement() on <a>
again. Thus, the assertion that extractedStyle is not null is reasonable.
Hence, this patch fixes this bug by skipping over atomic nodes when we apply style.

Test: editing/style/apply-style-atomic.html

* editing/ApplyStyleCommand.cpp:
(WebCore::ApplyStyleCommand::removeStyleFromRunBeforeApplyingStyle):
(WebCore::ApplyStyleCommand::removeInlineStyle):

LayoutTests:

* editing/style/apply-style-atomic-expected.txt: Added.
* editing/style/apply-style-atomic.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@126865 268f45cc-cd09-0410-ab3c-d52691b4dbfc
eseidel pushed a commit that referenced this pull request Oct 15, 2012
https://bugs.webkit.org/show_bug.cgi?id=98997

Reviewed by Oliver Hunt.

Somewhat incidentally, the introduction of butterflies led to each indexing
type being represented by a unique bit. This is superficially nice since it
allows you to test if a structure corresponds to a particular indexing type
by saying !!(structure->indexingType() & TheType). But the downside is that
given the 8 bits we have for the m_indexingType field, that leaves only a
small number of possible indexing types if we have one per bit.
        
This changeset changes the indexing type to be:
        
Bit #1: Tells you if you're an array.
        
Bits #2 - WebKit#5: 16 possible indexing types, including the blank type for
    objects that don't have indexed properties.
        
Bits WebKit#6-8: Auxiliary bits that we could use for other things. Currently we
    just use one of those bits, for MayHaveIndexedAccessors.
        
This is performance-neutral, and is primarily intended to give us more
breathing room for introducing new inferred array modes.

* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::JumpList::jumps):
* assembler/MacroAssembler.h:
(MacroAssembler):
(JSC::MacroAssembler::patchableBranch32):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::patchableBranch32):
(MacroAssemblerARMv7):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::modeAlreadyChecked):
* dfg/DFGRepatch.cpp:
(JSC::DFG::tryCacheGetByID):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculationCheck):
(JSC::DFG::SpeculativeJIT::forwardSpeculationCheck):
(JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
(DFG):
(JSC::DFG::SpeculativeJIT::checkArray):
(JSC::DFG::SpeculativeJIT::arrayify):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* jit/JITInlineMethods.h:
(JSC::JIT::emitAllocateJSArray):
(JSC::JIT::chooseArrayMode):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitContiguousGetByVal):
(JSC::JIT::emitArrayStorageGetByVal):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitContiguousPutByVal):
(JSC::JIT::emitArrayStoragePutByVal):
(JSC::JIT::privateCompilePatchGetArrayLength):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emitContiguousGetByVal):
(JSC::JIT::emitArrayStorageGetByVal):
(JSC::JIT::emit_op_put_by_val):
(JSC::JIT::emitContiguousPutByVal):
(JSC::JIT::emitArrayStoragePutByVal):
(JSC::JIT::privateCompilePatchGetArrayLength):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/IndexingType.h:
(JSC):
(JSC::hasIndexedProperties):
(JSC::hasContiguous):
(JSC::hasFastArrayStorage):
(JSC::hasArrayStorage):
(JSC::shouldUseSlowPut):
* runtime/JSGlobalObject.cpp:
(JSC):
* runtime/StructureTransitionTable.h:
(JSC::newIndexingType):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131276 268f45cc-cd09-0410-ab3c-d52691b4dbfc
eseidel pushed a commit that referenced this pull request Oct 29, 2012
https://bugs.webkit.org/show_bug.cgi?id=99899

Reviewed by Ryosuke Niwa.

We cannot provide an elegant way to measure the memory consumption of the PageLoad tests, but we can turn them into simple
performance tests and measure their memory footprint and performance that way. This change moves and renames the related files
to their new location and adds html/js wrappers for them.

This is the #2 commit of the whole patch.

* PageLoad/svg/files/cacuts_01.svg: Removed.
* PageLoad/svg/files/cowboy.svg: Removed.
* PageLoad/svg/files/crawfish2_ganson.svg: Removed.
* SVG/Cactus.html: Added.
* SVG/Cowboy.html: Added.
* SVG/CrawFishGanson.html: Added.
* SVG/resources/Cactus.svg: Copied from PerformanceTests/PageLoad/svg/files/cacuts_01.svg.
* SVG/resources/Cowboy.svg: Copied from PerformanceTests/PageLoad/svg/files/cowboy.svg.
* SVG/resources/CrawFishGanson.svg: Copied from PerformanceTests/PageLoad/svg/files/crawfish2_ganson.svg.
* Skipped: Remove az-lizard_benji_park_01.svg from the skipped list.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@132506 268f45cc-cd09-0410-ab3c-d52691b4dbfc
eseidel pushed a commit that referenced this pull request Oct 29, 2012
https://bugs.webkit.org/show_bug.cgi?id=100623

Patch by Huang Dongsung <luxtella@company100.net> on 2012-10-29
Reviewed by Noam Rosenthal.

Currently, GraphicsLayerAnimation chooses a timing function in the wrong
way. Other GraphicsLayers choose a timing function in the similar way to
GraphicsLayerCA::timingFunctionForAnimationValue(). The way consists of
the following steps.
1. Try to query the timing function of the current keyframe animation value.
2. If the timing function of #1 is null, try to query the timing function of Animation.
3. If the timing function of #2 is null, return CubicBezierTimingFunction::defaultTimingFunction().

This patch makes GraphicsLayerAnimation choose a timing function in the same way
to other implementations.

Covered by existing animations tests.

* platform/graphics/GraphicsLayerAnimation.cpp:
(WebCore::timingFunctionForAnimationValue):
(WebCore::GraphicsLayerAnimation::apply):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@132798 268f45cc-cd09-0410-ab3c-d52691b4dbfc
eseidel referenced this pull request Dec 21, 2012
https://bugs.webkit.org/show_bug.cgi?id=105326

Patch by Huang Dongsung <luxtella@company100.net> on 2012-12-20
Reviewed by Noam Rosenthal.

Clear a drawing buffer after compositing if preserveDrawingBuffer is
false.
http://www.khronos.org/registry/webgl/specs/latest/#2.2

No new tests. Covered by existing webgl-preserve-drawing-buffer-repaint test.

* platform/graphics/cairo/GraphicsContext3DPrivate.cpp:
(WebCore::GraphicsContext3DPrivate::paintToTextureMapper):
* platform/graphics/efl/GraphicsContext3DPrivate.cpp:
(GraphicsContext3DPrivate::copyToGraphicsSurface):
* platform/graphics/qt/GraphicsContext3DQt.cpp:
(WebCore::GraphicsContext3DPrivate::paintToTextureMapper):
(WebCore::GraphicsContext3DPrivate::copyToGraphicsSurface):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138346 268f45cc-cd09-0410-ab3c-d52691b4dbfc
theiostream pushed a commit to theiostream/webkit that referenced this pull request May 15, 2017
…sts)

https://bugs.webkit.org/show_bug.cgi?id=85340

Reviewed by Adam Barth.

Source/WebCore:

This code was primarily written by Adam Barth and then submitted to my
GitHub branch via a pull request:
eseidel/webkit@master...seamless
eseidel#2
eseidel#3

I rewrote parts of it to use Docment::shouldDisplaySeamlesslyWithParent.

Other parts of the original change have already been committed to WebKit by Adam
as part of prep-work for making the loader seamless-ready.

* loader/FrameLoader.cpp:
(WebCore::FrameLoader::findFrameForNavigation):

LayoutTests:

Update results now that we pass all the navigation tests.

* fast/frames/seamless/seamless-form-get-expected.txt:
* fast/frames/seamless/seamless-form-get-named-expected.txt:
* fast/frames/seamless/seamless-form-post-expected.txt:
* fast/frames/seamless/seamless-form-post-named-expected.txt:
* fast/frames/seamless/seamless-hyperlink-expected.txt:
* fast/frames/seamless/seamless-hyperlink-named-expected.txt:
* fast/frames/seamless/seamless-window-location-expected.txt:
* fast/frames/seamless/seamless-window-location-href-expected.txt:
* fast/frames/seamless/seamless-window-location-sandbox-expected.txt:
* fast/frames/seamless/seamless-window-open-expected.txt:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@115796 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants