Timeline
Nov 4, 2012:
- 11:55 PM Changeset in webkit [133439] by
-
- 8 edits4 adds in trunk
Fix the collapsing border code to handle mixed directionality at the row level
https://bugs.webkit.org/show_bug.cgi?id=101060
Reviewed by Ojan Vafai.
Source/WebCore:
After bug 87900, we support mixed directionality at the row-group level. For coherency
- as the underlying code didn't support it - we were artificially ignoring 'direction'
below the row-group. This change relaxes the restriction and patches the collapsing
borders code to query the right style and border.
Tests: fast/table/border-collapsing/table-ltr-rows-mixed-direction.html
fast/table/border-collapsing/table-rtl-row-mixed-direction.html
- rendering/RenderTable.cpp:
(WebCore::RenderTable::tableStartBorderAdjoiningCell):
(WebCore::RenderTable::tableEndBorderAdjoiningCell):
Changed to query the row's direction.
- rendering/RenderTableCell.cpp:
(WebCore::RenderTableCell::hasStartBorderAdjoiningTable):
(WebCore::RenderTableCell::hasEndBorderAdjoiningTable):
Added 2 helper functions. They determine if a specific cell's border
adjoins the table. This code is required as the last cell's end border
can be resolved against the start border.
(WebCore::RenderTableCell::computeCollapsedStartBorder):
(WebCore::RenderTableCell::computeCollapsedEndBorder):
Updated these functions now that being the start / end column doesn't mean
that we have to resolve against the row / row-group / table's border.
- rendering/RenderTableCell.h:
(WebCore::RenderTableCell::styleForCellFlow):
Updated to return the row's style.
- rendering/RenderTableRow.cpp:
(WebCore::RenderTableRow::borderAdjoiningStartCell):
(WebCore::RenderTableRow::borderAdjoiningEndCell):
- rendering/RenderTableSection.cpp:
(WebCore::RenderTableSection::borderAdjoiningStartCell):
(WebCore::RenderTableSection::borderAdjoiningEndCell):
Updated these functions to work with mixed directionality.
- rendering/RenderTableSection.cpp:
(WebCore::RenderTableSection::setLogicalPositionForCell):
Changed this function to use the section's direction. This is wrong and should be changed
once we properly fix the collapsing border code.
(WebCore::RenderTableSection::logicalRectForWritingModeAndDirection):
Added a FIXME.
- rendering/style/CollapsedBorderValue.h:
(WebCore::CollapsedBorderValue::width):
This is a bug in our implementation: we used to return a non-zero width for inexistant borders (per CSS 2.1,
'border-style: off | hidden' should have a 0 width). This is covered by our existing tests (among others by
fast/table/border-collapsing/last-cell-left-border-hidden-table-ltr-section-rtl.html).
LayoutTests:
- fast/table/border-collapsing/table-ltr-rows-mixed-direction-expected.html: Added.
- fast/table/border-collapsing/table-ltr-rows-mixed-direction.html: Added.
- fast/table/border-collapsing/table-rtl-row-mixed-direction-expected.html: Added.
- fast/table/border-collapsing/table-rtl-row-mixed-direction.html: Added.
- 11:52 PM Changeset in webkit [133438] by
-
- 4 edits1 move5 adds in trunk
Web Inspector: [Canvas] do not blow up the capturing log
https://bugs.webkit.org/show_bug.cgi?id=100752
Patch by Andrey Adaikin <aandrey@chromium.org> on 2012-11-04
Reviewed by Pavel Feldman.
Source/WebCore:
Clear obsolete calls in the canvas 2D capturing log in runtime.
Now we store in the log only minimum number of calls that are necessary to replay a
canvas 2D context. To achieve that we find in runtime those calls in the log that no
longer contribute to the final context state and remove them.
These are the rules according which we find and remove such calls:
- all PATH methods between a clip() call and beginPath() call can be removed
- all MATRIX methods before a restore() or setTransform() call but after any PATH or corresponding save() method
- all consecutive save() + restore() calls
Tests: inspector/profiler/canvas2d/canvas2d-api-changes.html
inspector/profiler/canvas2d/canvas2d-profiler-capturing-basics.html
- inspector/InjectedScriptCanvasModuleSource.js:
(.):
LayoutTests:
Added test for track Canvas 2D API changes, as well as basics for the capturing.
- inspector/profiler/canvas-profiler-test.js: Renamed from LayoutTests/inspector/profiler/webgl/webgl-profiler-test.js.
(initialize_CanvasWebGLProfilerTest.InspectorTest.enableCanvasAgent):
(initialize_CanvasWebGLProfilerTest):
(createWebGLContext):
(createCanvas2DContext):
- inspector/profiler/canvas2d/canvas2d-api-changes-expected.txt: Added.
- inspector/profiler/canvas2d/canvas2d-api-changes.html: Added.
- inspector/profiler/canvas2d/canvas2d-profiler-capturing-basics-expected.txt: Added.
- inspector/profiler/canvas2d/canvas2d-profiler-capturing-basics.html: Added.
- inspector/profiler/webgl/webgl-profiler-get-error.html:
- 11:49 PM Changeset in webkit [133437] by
-
- 2 edits in trunk/LayoutTests
[Qt] Unreviewed gardening.
Skip a new failing test introduced in r133428, because SHADOW_DOM is disabled.
Unskip a test that does not exist already.
Patch by Nandor Huszka <hnandor@inf.u-szeged.hu> on 2012-11-04
- platform/qt/TestExpectations:
- 11:30 PM Changeset in webkit [133436] by
-
- 2 edits1 add in trunk/LayoutTests
Unreviewed GTK gardening.
Adding failure expectations for accessibility/svg-remote-element,
fast/images/exif-orientation-image-document.html and
svg/animations/mozilla/animateMotion-mpath-targetChange-1.svg.
Rebaselining fast/images/repaint-subrect-grid.html, the new baseline
matches the one Mac port uses.
- platform/gtk/TestExpectations:
- platform/gtk/fast/images/repaint-subrect-grid-expected.txt: Added.
- 11:29 PM Changeset in webkit [133435] by
-
- 2 edits in trunk/Source/WebCore
[Shadow] ShadowRoot should have a method to return ShadowRootType.
https://bugs.webkit.org/show_bug.cgi?id=101178
Reviewed by Hajime Morita.
When we style PseudoCustomElement, we have to know ShadowRootType.
We would like to expose a method to get ShadowRootType also in Release mode.
This is a preparation patch for Bug 101170.
- dom/ShadowRoot.h:
(ShadowRoot):
- 11:13 PM Changeset in webkit [133434] by
-
- 8 edits in trunk
Introduce Month class to calendar picker
https://bugs.webkit.org/show_bug.cgi?id=101024
Reviewed by Kent Tamura.
Source/WebCore:
Month class needs to be introduced to implement a month picker. This
patch just introduces the Month class into the calendar picker without
changing the current behavior.
No new tests. Covered by existing calendar-picker-*.html tests.
- Resources/pagepopups/calendarPicker.js:
(Month.prototype.toLocaleString): Returns a localized month string.
(Month): Takes a Month object, number representing the month, or year and month numbers.
(Month.parse): Returns a new Month from an ISO month string.
(Month.createFromDate): Returns a new Month containing the given datetime.
(Month.prototype.equals): Returns true if the given month is the same.
(Month.prototype.previous): Returns the previous month.
(Month.prototype.next): Returns the next month.
(Month.prototype.startDate): Returns a datetime that is the start of this month. The value is inclusive.
(Month.prototype.endDate): Returns a datetime that is the end of this month. The value is exclusive.
(Month.prototype.valueOf): Returns a number representing the month.
(Month.prototype.toString): Returns an ISO month string.
(YearMonthController): Use Month object.
(YearMonthController.prototype.attachTo): Year 275760 ends in September so use the year before to measure the label width.
(YearMonthController.prototype.setMonth): Take a month object.
(YearMonthController.prototype._redraw): Use ISO month string for element.dataset.value.
(YearMonthController.prototype._handleYearMonthChange):
(YearMonthController.prototype.moveRelatively):
(DaysTable): Use Month object.
(DaysTable.prototype._renderMonth): Take a month object. Testing for isNaN is moved up to fix a bug when showing September, 275760.
(DaysTable.prototype._navigateToMonth): Take a month object.
(DaysTable.prototype._navigateToMonthWithAnimation): Take a month object.
(DaysTable.prototype.navigateToMonthAndKeepSelectionPosition): Take a month object.
(DaysTable.prototype.selectDate):
(DaysTable.prototype._maybeSetPreviousMonth): Use Month object to calculate the previous month.
(DaysTable.prototype._maybeSetNextMonth): Use Month object to calculate the next month.
LayoutTests:
- platform/chromium-win/platform/chromium/fast/forms/calendar-picker/calendar-picker-key-operations-expected.txt:
- platform/chromium/fast/forms/calendar-picker/calendar-picker-key-operations-expected.txt:
- platform/chromium/fast/forms/calendar-picker/calendar-picker-key-operations.html: Adjust the expectation because we changed the month string format.
- platform/chromium/fast/forms/calendar-picker/calendar-picker-mouse-operations-expected.txt:
- platform/chromium/fast/forms/calendar-picker/calendar-picker-mouse-operations.html: Ditto.
- 10:17 PM Changeset in webkit [133433] by
-
- 2 edits31 deletes in trunk/LayoutTests
Remove obsolete tests for date/time input types
https://bugs.webkit.org/show_bug.cgi?id=98783
Reviewed by Kentaro Hara.
*-input-visible-string.html and *-stepup-stepdown-from-renderer.html are
unnecessary and should be removed because they depend on textfield
behavior, and the date/time input types no longer have textfield
behavior on any platforms.
- fast/forms/datetime/datetime-input-visible-string-expected.txt: Removed.
- fast/forms/datetime/datetime-input-visible-string.html: Removed.
- fast/forms/datetime/datetime-stepup-stepdown-from-renderer-expected.txt: Removed.
- fast/forms/datetime/datetime-stepup-stepdown-from-renderer.html: Removed.
- fast/forms/datetimelocal/datetimelocal-input-visible-string-expected.txt: Removed.
- fast/forms/datetimelocal/datetimelocal-input-visible-string.html: Removed.
- fast/forms/datetimelocal/datetimelocal-stepup-stepdown-from-renderer-expected.txt: Removed.
- fast/forms/datetimelocal/datetimelocal-stepup-stepdown-from-renderer.html: Removed.
- fast/forms/month/month-input-visible-string-expected.txt: Removed.
- fast/forms/month/month-input-visible-string.html: Removed.
- fast/forms/month/month-stepup-stepdown-from-renderer-expected.txt: Removed.
- fast/forms/month/month-stepup-stepdown-from-renderer.html: Removed.
- fast/forms/time/time-input-visible-string-expected.txt: Removed.
- fast/forms/time/time-input-visible-string.html: Removed.
- fast/forms/time/time-stepup-stepdown-from-renderer-expected.txt: Removed.
- fast/forms/time/time-stepup-stepdown-from-renderer.html: Removed.
- fast/forms/week/week-input-visible-string-expected.txt: Removed.
- fast/forms/week/week-input-visible-string.html: Removed.
- fast/forms/week/week-stepup-stepdown-from-renderer-expected.txt: Removed.
- fast/forms/week/week-stepup-stepdown-from-renderer.html: Removed.
- platform/chromium-android/fast/forms/time/time-stepup-stepdown-from-renderer-expected.txt: Removed.
- platform/chromium/TestExpectations:
- platform/chromium/fast/forms/datetime/datetime-input-visible-string-expected.txt: Removed.
- platform/chromium/fast/forms/datetime/datetime-stepup-stepdown-from-renderer-expected.txt: Removed.
- platform/chromium/fast/forms/datetimelocal/datetimelocal-input-visible-string-expected.txt: Removed.
- platform/chromium/fast/forms/datetimelocal/datetimelocal-stepup-stepdown-from-renderer-expected.txt: Removed.
- platform/chromium/fast/forms/month/month-input-visible-string-expected.txt: Removed.
- platform/chromium/fast/forms/month/month-stepup-stepdown-from-renderer-expected.txt: Removed.
- platform/chromium/fast/forms/time/time-input-visible-string-expected.txt: Removed.
- platform/chromium/fast/forms/time/time-stepup-stepdown-from-renderer-expected.txt: Removed.
- platform/chromium/fast/forms/week/week-input-visible-string-expected.txt: Removed.
- platform/chromium/fast/forms/week/week-stepup-stepdown-from-renderer-expected.txt: Removed.
- 9:35 PM FeatureFlags edited by
- Remove UNDO_MANAGER (diff)
- 9:33 PM Changeset in webkit [133432] by
-
- 6 edits in trunk/Source
[EFL] Use _LIBRARIES instead of _LIBRARY
https://bugs.webkit.org/show_bug.cgi?id=101042
Patch by Halton Huo <halton.huo@intel.com> on 2012-11-04
Reviewed by Gyuyoung Kim.
In CMake Find files, _LIBRARY is intended for internal use, should
use _LIBRARIES instead.
Source/WebCore:
- PlatformEfl.cmake: s/_LIBRARY}/_LIBRARIES}
Source/WebKit:
- PlatformEfl.cmake: s/_LIBRARY}/_LIBRARIES}
Source/WebKit2:
- PlatformEfl.cmake: s/_LIBRARY}/_LIBRARIES}
- 9:22 PM Changeset in webkit [133431] by
-
- 2 edits in trunk/LayoutTests
[EFL][DRT] Skip a fast/images/repaint-subrect-grid.html test case after r133322
https://bugs.webkit.org/show_bug.cgi?id=101175
Unreviewed gardening.
fast/images/repaint-subrect-grid.html is failing on WK1 debug bot.
Patch by Jinwoo Song <jinwoo7.song@samsung.com> on 2012-11-04
- platform/efl-wk1/TestExpectations:
- 7:13 PM Changeset in webkit [133430] by
-
- 4 edits in trunk/Source/JavaScriptCore
Baseline JIT should use structure watchpoints whenever possible
https://bugs.webkit.org/show_bug.cgi?id=101146
Reviewed by Sam Weinig.
No speed-up yet except on toy programs. I think that it will start to show
speed-ups with https://bugs.webkit.org/show_bug.cgi?id=101147, which this is
a step towards.
- jit/JIT.h:
(JIT):
- jit/JITPropertyAccess.cpp:
(JSC::JIT::privateCompilePutByIdTransition):
(JSC::JIT::privateCompileGetByIdProto):
(JSC::JIT::privateCompileGetByIdProtoList):
(JSC::JIT::privateCompileGetByIdChainList):
(JSC::JIT::privateCompileGetByIdChain):
(JSC::JIT::addStructureTransitionCheck):
(JSC):
(JSC::JIT::testPrototype):
- jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::privateCompilePutByIdTransition):
(JSC::JIT::privateCompileGetByIdProto):
(JSC::JIT::privateCompileGetByIdProtoList):
(JSC::JIT::privateCompileGetByIdChainList):
(JSC::JIT::privateCompileGetByIdChain):
- 7:09 PM Changeset in webkit [133429] by
-
- 10 edits in trunk/Source
Shadow DOM should be able to be disabled per context.
https://bugs.webkit.org/show_bug.cgi?id=101173
Reviewed by Dimitri Glazkov.
Source/WebCore:
This change pulls back relevant bits from r131549. Note that if
the the port enables runtime Shadow DOM flag, this can cause slow
down on some Chromium page cycler test cases (which r131549
attempted to fix).
This change is temporal and the flags should be switched back from
ContextFeatures to RuntimeEnabledFeatures once it gains sufficent
stability.
- dom/ContextFeatures.cpp:
(WebCore::ContextFeatures::shadowDOMEnabled):
(WebCore):
- dom/ContextFeatures.h:
- dom/Position.cpp:
(WebCore::Position::Position):
(WebCore::Position::findParent):
- dom/TreeScope.cpp:
(WebCore::TreeScope::getSelection):
- html/HTMLTagNames.in:
- html/shadow/HTMLContentElement.cpp:
(WebCore::HTMLContentElement::contentTagName):
- page/DOMWindow.idl:
Source/WebKit/chromium:
- src/ContextFeaturesClientImpl.cpp:
(WebKit::ContextFeaturesClientImpl::askIfIsEnabled):
- 7:04 PM Changeset in webkit [133428] by
-
- 5 edits2 adds in trunk
[Shadow] Implement custom pseudo-elements styling
https://bugs.webkit.org/show_bug.cgi?id=100812
Reviewed by Hajime Morita.
Source/WebCore:
Instead of using ElementRareData::m_shadowPseudoId, we use 'pseudo' attribute.
Later we would like to remove Element::shadowPseudoId and Element::setShadowPseudoId
and use pseudo()/setPseudo() instead (Bug 101171).
Test: fast/dom/shadow/styling-pseudo-attribute.html
- dom/Element.cpp:
(WebCore::Element::shadowPseudoId):
(WebCore::Element::setShadowPseudoId):
- dom/ElementRareData.cpp:
(WebCore::ElementRareData::reportMemoryUsage):
- dom/ElementRareData.h:
(ElementRareData):
LayoutTests:
- fast/dom/shadow/styling-pseudo-attribute-expected.html: Added.
- fast/dom/shadow/styling-pseudo-attribute.html: Added.
- 3:16 PM Changeset in webkit [133427] by
-
- 6 edits in trunk/Source/WebCore
BaseChooserOnlyDateAndTimeInputType should have BaseClickableWithKeyInputType behavior
https://bugs.webkit.org/show_bug.cgi?id=101039
Reviewed by Hajime Morita.
Add BaseClickableWithKeyInputType behavior to
BaseChooserOnlyDateAndTimeInputType. It means date/time input types
without ENABLE_INPUT_MULTIPLE_FIELDS_UI receive DOMActivate events by
pressing space or enter key. They're going to open a date/time chooser
by DOMActive event.
Because BaseChooserOnlyDateAndTimeInputType inherits from
BaseDateAndTimeInputType, it can't inherit
BaseClickableWithKeyInputType. So, this patch adds static helper
functions to BaseClickableWithKeyInputType, and
BaseChooserOnlyDateAndTimeInputType uses them.
This patch doesn't change behavior yet because Chromimum-Android port
intercepts user events and doesn't deliver them to date/time input
elements.
- html/BaseChooserOnlyDateAndTimeInputType.cpp:
(WebCore::BaseChooserOnlyDateAndTimeInputType::handleDOMActivateEvent):
Add an empty implementation with a FIXME comment.
(WebCore::BaseChooserOnlyDateAndTimeInputType::handleKeydownEvent):
Add BaseClickableWithKeyInputType behavior by a helper function.
(WebCore::BaseChooserOnlyDateAndTimeInputType::handleKeypressEvent): Ditto.
(WebCore::BaseChooserOnlyDateAndTimeInputType::handleKeyupEvent): Ditto.
(WebCore::BaseChooserOnlyDateAndTimeInputType::accessKeyAction): Ditto.
- html/BaseChooserOnlyDateAndTimeInputType.h:
(BaseChooserOnlyDateAndTimeInputType): Add function declarations.
- html/BaseClickableWithKeyInputType.cpp:
Add static helper functions, and existing member functions use them.
- html/BaseClickableWithKeyInputType.h:
(BaseClickableWithKeyInputType): Add declarations of the helper functions.
- html/InputType.h:
(InputType): Make dispatchSimulatedClickIfActive public because it is
called from a helper function.
- 2:30 PM Changeset in webkit [133426] by
-
- 4 edits2 deletes in trunk
Unreviewed, rolling out r133416.
http://trac.webkit.org/changeset/133416
https://bugs.webkit.org/show_bug.cgi?id=101169
Broke world selection by right click (Requested by rniwa on
#webkit).
Patch by Sheriff Bot <webkit.review.bot@gmail.com> on 2012-11-04
Source/WebCore:
- page/EventHandler.cpp:
(WebCore::EventHandler::handleGestureForTextSelectionOrContextMenu):
(WebCore::EventHandler::sendContextMenuEvent):
LayoutTests:
- fast/events/touch/gesture/disabled-input-text-selection-expected.txt: Removed.
- fast/events/touch/gesture/disabled-input-text-selection.html: Removed.
- platform/chromium/TestExpectations:
- 2:26 PM Changeset in webkit [133425] by
-
- 5 edits in trunk/Source/WebKit2
Expose security origin to BundleFrame
https://bugs.webkit.org/show_bug.cgi?id=101139
<rdar://problem/12629900>
Reviewed by Darin Adler.
Create a WebSecurityOrigin instance, sharing the security origin instance
that comes directly from the frame's document. We can do this because the
WK2 API only retrieves information about the origin, and because those
results are returned as copies. The security origin holds no references
that could lead to a retain cycle, avoiding the possibility that the
injected bundle accidentally keeps something alive.
- Shared/API/c/WKSharedAPICast.h:
(WebKit::toCopiedAPI): Create copied API for WebCore::SecurityOrigin
instances.
- Shared/WebSecurityOrigin.h:
(WebKit::WebSecurityOrigin::create): Add a new create() function that
takes a PassRefPtr to a WebCore SecurityOrigin instance.
(WebKit::WebSecurityOrigin::createFromString): Refactor to use new create()
function.
(WebKit::WebSecurityOrigin::createFromDatabaseIdentifier): Refactor to
use new create() function.
(WebKit::WebSecurityOrigin::create): Refactor to use new create()
function.
- WebProcess/InjectedBundle/API/c/WKBundleFrame.cpp:
(WKBundleFrameCopySecurityOrigin): Add function to retrieve the security
origin as a WK2 API object.
- WebProcess/InjectedBundle/API/c/WKBundleFrame.h:
- 9:27 AM Changeset in webkit [133424] by
-
- 2 edits in trunk/Source/WebCore
Missing ASCIILiteral in a place of accessibility
https://bugs.webkit.org/show_bug.cgi?id=101160
Reviewed by Darin Adler.
ASCIILiteral usage is being missed in a spot of accessibliity.
- accessibility/AccessibilityMediaControls.cpp:
(WebCore::AccessibilityMediaTimeDisplay::accessibilityDescription):
- 8:02 AM Changeset in webkit [133423] by
-
- 4 edits in trunk/Source/WebKit2
[EFL] Unify transforms in WK2
https://bugs.webkit.org/show_bug.cgi?id=101051
Reviewed by Simon Hausmann.
Move our transforms into EwkViewImpl and use them
everywhere needed.
- UIProcess/API/efl/EwkViewImpl.cpp:
(EwkViewImpl::smartData):
(EwkViewImpl::transformFromScene):
(EwkViewImpl::transformToScene):
(EwkViewImpl::transformToScreen):
(EwkViewImpl::displayTimerFired):
- UIProcess/API/efl/EwkViewImpl.h:
(WebCore):
(EwkViewImpl):
(EwkViewImpl::pageViewportControllerClient):
(EwkViewImpl::pageViewportController):
- UIProcess/API/efl/ewk_view.cpp:
(_ewk_view_smart_mouse_wheel):
(_ewk_view_smart_mouse_down):
(_ewk_view_smart_mouse_up):
(_ewk_view_smart_mouse_move):
(ewk_view_feed_touch_event):
- 6:57 AM Changeset in webkit [133422] by
-
- 2 edits in trunk/LayoutTests
[chromium] Add a now-failing test. Unreviewed.
- platform/chromium/TestExpectations:
- 6:07 AM Changeset in webkit [133421] by
-
- 16 edits1 move1 add3 deletes in trunk
[Qt][WK2] setPlatformStrategies always asserts after r132744
https://bugs.webkit.org/show_bug.cgi?id=100838
Reviewed by Simon Hausmann.
Reland with build fixes.
Source/WebCore:
The problem here is that we use QWebSettings::clearMemoryCaches, a WebKit1 API
from the injected bundle, which calls initializeWebCoreQt and it sets the platform
strategies to the one for WebKit1. We should stop using WebKit1 API's from WebKit2
code. In order to keep the behavior, this patch adds exported helpers to WebCore
that can be used from DumpRenderTree and WebKitTestRunner. This is the same idea
as WebCoreTestSupport but these helpers are specific to Qt. Technically we could
add it to the WebKit1 API for the time being, but my goal was to move in the direction
of removing the WebKit1 dependency from WebKitTestRunner. We only build the file
in non production mode.
Basically covered by all tests.
- Target.pri:
- WebCore.pri: We need to link against fontconfig (only in non-production mode) since
initializeTestFonts uses it.
- platform/qt/QtTestSupport.cpp: Added. I choose GPL license because code from qwebsettings.cpp
is also under that.
(WebKit):
(WebKit::QtTestSupport::clearMemoryCaches): This is basically a copy of QWebSettings::clearMemoryCaches
without calling initializeWebCoreQt.
(WebKit::QtTestSupport::initializeTestFonts): I moved this code here as well now that we have to expose
symbols from WebCore anyway. The advantage is that now we don't have to build it twice and we don't need
additional files to forward it from the directory of DumpRenderTree for WebKitTestRunner.
I added a call to FontCace::invalidate in the case when the font set has been changed so that it will do
the job even if we would stop clearing all caches between tests. Also moved the call to
QFontDatabase::removeAllApplicationFonts from callers to here.
- platform/qt/QtTestSupport.h:
(WebKit):
(QtTestSupport):
Tools:
Turned test runners to use the new QtTestSupport.
- DumpRenderTree/qt/DumpRenderTree.pro:
- DumpRenderTree/qt/DumpRenderTreeMain.cpp:
(main):
- DumpRenderTree/qt/DumpRenderTreeQt.cpp:
(WebCore::DumpRenderTree::open):
- DumpRenderTree/qt/QtInitializeTestFonts.h: Removed.
- MiniBrowser/qt/MiniBrowser.pro:
- QtTestBrowser/QtTestBrowser.pro:
- QtTestBrowser/qttestbrowser.cpp:
(LauncherApplication::handleUserOptions):
- WebKitTestRunner/InjectedBundle/Target.pri:
- WebKitTestRunner/InjectedBundle/qt/ActivateFontsQt.cpp:
(WTR::activateFonts):
- WebKitTestRunner/InjectedBundle/qt/QtInitializeTestFonts.cpp: Removed.
- WebKitTestRunner/InjectedBundle/qt/QtInitializeTestFonts.h: Removed.
- WebKitTestRunner/InjectedBundle/qt/TestRunnerQt.cpp:
(WTR::TestRunner::platformInitialize): Removed the comment from here
because it was just lying, apparently two times. First, it is not incorrect
to reinitialize our font set and clear font caches, it is what the tests
expect. Second, the use of QRawFont has nothing to do with the font cache.
- WebKitTestRunner/Target.pri:
- WebKitTestRunner/qt/main.cpp:
(main):
- 5:26 AM Changeset in webkit [133420] by
-
- 3 edits2 adds in trunk
Color-profile property triggers assert
https://bugs.webkit.org/show_bug.cgi?id=101080
Reviewed by Dirk Schulze.
Source/WebCore:
CSSPropertyColorProfile is not handled in StyleResolver::applySVGProperty(), triggering the
unimplemented property assert. Adding a stub entry to avoid that.
Test: svg/css/color-profile-crash.html
- css/SVGCSSStyleSelector.cpp:
(WebCore::StyleResolver::applySVGProperty):
LayoutTests:
- svg/css/color-profile-crash-expected.txt: Added.
- svg/css/color-profile-crash.html: Added.
- 4:30 AM Changeset in webkit [133419] by
-
- 5 edits in trunk/LayoutTests
[Qt][WK2] Unreviewed weekend gardening, skip failing tests, update expected files.
- platform/qt-5.0-wk2/TestExpectations:
- platform/qt-5.0-wk2/http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-expected.txt: Updated after r133019.
- platform/qt-5.0-wk2/http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-in-body-expected.txt: Updated after r133019.
- platform/qt-5.0-wk2/http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-parent-same-origin-deny-expected.txt: Updated after r133019.
- 2:55 AM Changeset in webkit [133418] by
-
- 2 edits in trunk/LayoutTests
[Qt] Unreviewed weekend gardening, skip one more failing test.
- platform/qt/TestExpectations:
- 2:31 AM Changeset in webkit [133417] by
-
- 2 edits in trunk/LayoutTests
[Qt] Unreviewed weekend gardening, skip new failing tests.
- platform/qt/TestExpectations:
- 1:20 AM Changeset in webkit [133416] by
-
- 4 edits2 adds in trunk
Unable to copy text on disabled input fields on long press gesture
https://bugs.webkit.org/show_bug.cgi?id=99698
Reviewed by Ryosuke Niwa.
Text from disabled input/text should be allowed to select. Replaced isContentEditable()
with canStartSelection()
Source/WebCore:
Test: fast/events/touch/gesture/disabled-input-text-selection.html
- page/EventHandler.cpp:
(WebCore::EventHandler::handleGestureLongPress):
LayoutTests:
- fast/events/touch/gesture/disabled-input-text-selection-expected.txt: Added.
- fast/events/touch/gesture/disabled-input-text-selection.html: Added.
- platform/chromium/TestExpectations: Not Valid for chromium desktop.
Nov 4, 2012:
- 1:07 AM Changeset in webkit [133415] by
-
- 4 edits in trunk/Source/JavaScriptCore
[Qt] udis86_itab.c is always regenerated
https://bugs.webkit.org/show_bug.cgi?id=100756
Reviewed by Simon Hausmann.
- DerivedSources.pri: Generate sources to the generated directory.
- disassembler/udis86/differences.txt:
- disassembler/udis86/itab.py: Add --outputDir option.
(UdItabGenerator.init):
(genItabH):
(genItabC):
(main):
- 1:03 AM Changeset in webkit [133414] by
-
- 4 edits in trunk/Tools
Unreviewed, rolling out r133381.
http://trac.webkit.org/changeset/133381
https://bugs.webkit.org/show_bug.cgi?id=101161
It made webkit-patch useless (Requested by Ossy_weekend on
Patch by Sheriff Bot <webkit.review.bot@gmail.com> on 2012-11-04
- Scripts/webkitpy/common/system/autoinstall.py:
(AutoInstaller._create_scratch_directory):
(AutoInstaller._install):
(AutoInstaller.install):
- Scripts/webkitpy/thirdparty/init.py:
(AutoinstallImportHook.init):
(AutoinstallImportHook._install_pylint):
(AutoinstallImportHook._install_coverage):
(AutoinstallImportHook._install_eliza):
(AutoinstallImportHook._install):
- Scripts/webkitpy/thirdparty/init_unittest.py:
(ThirdpartyTest.test_import_hook.MockImportHook.init):
(ThirdpartyTest.test_import_hook):
- 12:43 AM Changeset in webkit [133413] by
-
- 2 edits in trunk/LayoutTests
[chromium] Remove some no-longer-flaky tests. Unreviewed.
- platform/chromium/TestExpectations:
Nov 3, 2012:
- 6:06 PM Changeset in webkit [133412] by
-
- 2 edits in trunk/LayoutTests
[chromium] Remove some a no-longer-flaky test. Unreviewed.
- platform/chromium/TestExpectations:
- 5:57 PM Changeset in webkit [133411] by
-
- 16 edits3 copies1 move1 delete in trunk
Unreviewed, rolling out r133403, r133404, and r133409.
http://trac.webkit.org/changeset/133403
http://trac.webkit.org/changeset/133404
http://trac.webkit.org/changeset/133409
https://bugs.webkit.org/show_bug.cgi?id=101158
"Broke tests" (Requested by kbalazs on #webkit).
Patch by Sheriff Bot <webkit.review.bot@gmail.com> on 2012-11-03
Source/WebCore:
- Target.pri:
- WebCore.pri:
- platform/qt/QtTestSupport.h: Removed.
Tools:
- DumpRenderTree/qt/DumpRenderTree.pro:
- DumpRenderTree/qt/DumpRenderTreeMain.cpp:
(main):
- DumpRenderTree/qt/DumpRenderTreeQt.cpp:
(WebCore::DumpRenderTree::open):
- DumpRenderTree/qt/QtInitializeTestFonts.cpp: Renamed from Source/WebCore/platform/qt/QtTestSupport.cpp.
(WebKit):
(WebKit::initializeTestFonts):
- DumpRenderTree/qt/QtInitializeTestFonts.h: Copied from Tools/WebKitTestRunner/InjectedBundle/qt/ActivateFontsQt.cpp.
(WebKit):
- MiniBrowser/qt/MiniBrowser.pro:
- MiniBrowser/qt/MiniBrowserApplication.cpp:
(MiniBrowserApplication::handleUserOptions):
- QtTestBrowser/QtTestBrowser.pro:
- QtTestBrowser/qttestbrowser.cpp:
(LauncherApplication::handleUserOptions):
- WebKitTestRunner/InjectedBundle/Target.pri:
- WebKitTestRunner/InjectedBundle/qt/ActivateFontsQt.cpp:
(WTR::activateFonts):
- WebKitTestRunner/InjectedBundle/qt/QtInitializeTestFonts.cpp: Copied from Tools/WebKitTestRunner/InjectedBundle/qt/ActivateFontsQt.cpp.
- WebKitTestRunner/InjectedBundle/qt/QtInitializeTestFonts.h: Copied from Tools/WebKitTestRunner/InjectedBundle/qt/ActivateFontsQt.cpp.
- WebKitTestRunner/InjectedBundle/qt/TestRunnerQt.cpp:
(WTR::TestRunner::platformInitialize):
- WebKitTestRunner/Target.pri:
- WebKitTestRunner/qt/main.cpp:
(main):
- 5:35 PM Changeset in webkit [133410] by
-
- 30 edits in trunk/Source
Get rid of USE(CFURLSTORAGESESSIONS)
https://bugs.webkit.org/show_bug.cgi?id=101131
Reviewed by Sam Weinig.
Source/WebCore:
This is always enabled on CFNetwork based platforms.
- WebCore.exp.in:
- page/Settings.cpp:
(WebCore::Settings::setPrivateBrowsingEnabled):
- platform/mac/CookieJar.mm:
(WebCore::cookies):
(WebCore::cookieRequestHeaderFieldValue):
(WebCore::setCookies):
(WebCore::cookiesEnabled):
(WebCore::getRawCookies):
(WebCore::deleteCookie):
- platform/network/ResourceHandle.h:
(ResourceHandle):
- platform/network/cf/CookieStorageCFNet.cpp:
(WebCore):
(WebCore::currentCFHTTPCookieStorage):
- platform/network/cf/CookieStorageCFNet.h:
- platform/network/cf/ResourceHandleCFNet.cpp:
(WebCore::willSendRequest):
(WebCore::makeFinalRequest):
(WebCore::ResourceHandle::willSendRequest):
(WebCore):
- platform/network/cf/ResourceRequest.h:
(ResourceRequest):
- platform/network/cf/ResourceRequestCFNet.cpp:
(WebCore::ResourceRequest::doUpdatePlatformRequest):
(WebCore):
- platform/network/mac/CookieStorageMac.mm:
(WebCore::setCookieStoragePrivateBrowsingEnabled):
- platform/network/mac/ResourceHandleMac.mm:
(WebCore::shouldRelaxThirdPartyCookiePolicy):
(WebCore::ResourceHandle::createNSURLConnection):
(WebCore::ResourceHandle::willSendRequest):
(WebCore):
- platform/network/mac/ResourceRequestMac.mm:
(WebCore):
(WebCore::ResourceRequest::setStorageSession):
Source/WebKit/blackberry:
- WebCoreSupport/AboutDataUseFeatures.in: Not sure what this list is about, but
CFURLSTORAGESESSIONS probably doesn't need to stay here.
Source/WebKit/mac:
- WebView/WebPreferences.mm:
(+[WebPreferences _switchNetworkLoaderToNewTestingSession]):
(+[WebPreferences _setCurrentNetworkLoaderSessionCookieAcceptPolicy:]):
- WebView/WebView.mm:
(-[WebView _cachedResponseForURL:]):
Source/WebKit2:
- Shared/WebProcessCreationParameters.cpp:
(WebKit::WebProcessCreationParameters::encode):
(WebKit::WebProcessCreationParameters::decode):
- Shared/WebProcessCreationParameters.h:
(WebProcessCreationParameters):
- UIProcess/win/WebContextWin.cpp:
(WebKit::WebContext::platformInitializeWebProcess):
- WebProcess/Cookies/mac/WebCookieManagerMac.mm:
(WebKit::WebCookieManager::platformSetHTTPCookieAcceptPolicy):
- WebProcess/InjectedBundle/InjectedBundle.cpp:
(WebKit::InjectedBundle::switchNetworkLoaderToNewTestingSession):
- WebProcess/WebPage/mac/WebPageMac.mm:
(WebKit::WebPage::platformHasLocalDataForURL):
(WebKit::cachedResponseForURL):
- WebProcess/WebPage/win/WebPageWin.cpp:
(WebKit::cachedResponseForURL):
- WebProcess/WebProcess.cpp:
(WebKit::WebProcess::initializeWebProcess):
- WebProcess/win/WebProcessWin.cpp:
(WebKit::WebProcess::platformSetCacheModel):
(WebKit::WebProcess::platformClearResourceCaches):
Source/WTF:
- wtf/Platform.h:
- 5:14 PM Changeset in webkit [133409] by
-
- 2 edits in trunk/Tools
[Qt][WK2] setPlatformStrategies always asserts after r132744
https://bugs.webkit.org/show_bug.cgi?id=100838
2nd unreviewed buildfix.
- MiniBrowser/qt/MiniBrowserApplication.cpp:
- 5:09 PM Changeset in webkit [133408] by
-
- 2 edits in trunk/LayoutTests
[chromium] Remove some now-passing tests. Unreviewed.
- platform/chromium/TestExpectations:
- 5:04 PM Changeset in webkit [133407] by
-
- 2 edits in tags/Safari-537.17.1/Source/WebCore
Merged r133398.
- 5:00 PM Changeset in webkit [133406] by
-
- 4 edits in tags/Safari-537.17.1/Source
Versioning.
- 4:57 PM Changeset in webkit [133405] by
-
- 1 copy in tags/Safari-537.17.1
New Tag.
- 4:47 PM Changeset in webkit [133404] by
-
- 2 edits in trunk/Tools
[Qt][WK2] setPlatformStrategies always asserts after r132744
https://bugs.webkit.org/show_bug.cgi?id=100838
Unreviewed buildfix.
- WebKitTestRunner/Target.pri:
- 3:52 PM Changeset in webkit [133403] by
-
- 15 edits1 move1 add3 deletes in trunk
[Qt][WK2] setPlatformStrategies always asserts after r132744
https://bugs.webkit.org/show_bug.cgi?id=100838
Reviewed by Simon Hausmann.
Reland with build fix.
Source/WebCore:
The problem here is that we use QWebSettings::clearMemoryCaches, a WebKit1 API
from the injected bundle, which calls initializeWebCoreQt and it sets the platform
strategies to the one for WebKit1. We should stop using WebKit1 API's from WebKit2
code. In order to keep the behavior, this patch adds exported helpers to WebCore
that can be used from DumpRenderTree and WebKitTestRunner. This is the same idea
as WebCoreTestSupport but these helpers are specific to Qt. Technically we could
add it to the WebKit1 API for the time being, but my goal was to move in the direction
of removing the WebKit1 dependency from WebKitTestRunner. We only build the file
in non production mode.
Basically covered by all tests.
- Target.pri:
- WebCore.pri: We need to link against fontconfig (only in non-production mode) since
initializeTestFonts uses it.
- platform/qt/QtTestSupport.cpp: Added. I choose GPL license because code from qwebsettings.cpp
is also under that.
(WebKit):
(WebKit::QtTestSupport::clearMemoryCaches): This is basically a copy of QWebSettings::clearMemoryCaches
without calling initializeWebCoreQt.
(WebKit::QtTestSupport::initializeTestFonts): I moved this code here as well now that we have to expose
symbols from WebCore anyway. The advantage is that now we don't have to build it twice and we don't need
additional files to forward it from the directory of DumpRenderTree for WebKitTestRunner.
I added a call to FontCace::invalidate in the case when the font set has been changed so that it will do
the job even if we would stop clearing all caches between tests. Also moved the call to
QFontDatabase::removeAllApplicationFonts from callers to here.
- platform/qt/QtTestSupport.h:
(WebKit):
(QtTestSupport):
Tools:
Turned test runners to use the new QtTestSupport.
- DumpRenderTree/qt/DumpRenderTree.pro:
- DumpRenderTree/qt/DumpRenderTreeMain.cpp:
(main):
- DumpRenderTree/qt/DumpRenderTreeQt.cpp:
(WebCore::DumpRenderTree::open):
- DumpRenderTree/qt/QtInitializeTestFonts.h: Removed.
- MiniBrowser/qt/MiniBrowser.pro:
- QtTestBrowser/QtTestBrowser.pro:
- QtTestBrowser/qttestbrowser.cpp:
(LauncherApplication::handleUserOptions):
- WebKitTestRunner/InjectedBundle/Target.pri:
- WebKitTestRunner/InjectedBundle/qt/ActivateFontsQt.cpp:
(WTR::activateFonts):
- WebKitTestRunner/InjectedBundle/qt/QtInitializeTestFonts.cpp: Removed.
- WebKitTestRunner/InjectedBundle/qt/QtInitializeTestFonts.h: Removed.
- WebKitTestRunner/InjectedBundle/qt/TestRunnerQt.cpp:
(WTR::TestRunner::platformInitialize): Removed the comment from here
because it was just lying, apparently two times. First, it is not incorrect
to reinitialize our font set and clear font caches, it is what the tests
expect. Second, the use of QRawFont has nothing to do with the font cache.
- WebKitTestRunner/Target.pri:
- WebKitTestRunner/qt/main.cpp:
(main):
- 3:36 PM Changeset in webkit [133402] by
-
- 10 edits2 moves in trunk/LayoutTests
[chromium] New baselines for no-longer-flaky tests. Unreviewed.
- platform/chromium-linux/compositing/geometry/fixed-position-transform-composited-page-scale-expected.png:
- platform/chromium-mac-lion/compositing/geometry/fixed-position-iframe-composited-page-scale-down-expected.png:
- platform/chromium-mac-lion/compositing/geometry/fixed-position-transform-composited-page-scale-down-expected.png:
- platform/chromium-mac-lion/compositing/geometry/fixed-position-transform-composited-page-scale-expected.png:
- platform/chromium-mac-snowleopard/compositing/geometry/fixed-position-iframe-composited-page-scale-down-expected.png:
- platform/chromium-mac/compositing/geometry/fixed-position-iframe-composited-page-scale-down-expected.png:
- platform/chromium-mac/compositing/geometry/fixed-position-transform-composited-page-scale-down-expected.png:
- platform/chromium-mac/compositing/geometry/fixed-position-transform-composited-page-scale-expected.png:
- platform/chromium-win/compositing/geometry/fixed-position-transform-composited-page-scale-expected.png:
- platform/chromium/TestExpectations:
- platform/efl-wk1/compositing/geometry/fixed-position-iframe-composited-page-scale-down-expected.png: Renamed from LayoutTests/platform/efl/compositing/geometry/fixed-position-iframe-composited-page-scale-down-expected.png.
- platform/efl-wk1/compositing/geometry/fixed-position-transform-composited-page-scale-expected.png: Renamed from LayoutTests/platform/efl/compositing/geometry/fixed-position-transform-composited-page-scale-expected.png.
- 3:27 PM Changeset in webkit [133401] by
-
- 2 edits in trunk/LayoutTests
[chromium] Unreviewed gardening.
- platform/chromium-win/compositing/geometry/fixed-position-transform-composited-page-scale-down-expected.png:
- 2:42 PM Changeset in webkit [133400] by
-
- 14 edits3 copies1 move1 delete in trunk
Unreviewed, rolling out r133397.
http://trac.webkit.org/changeset/133397
https://bugs.webkit.org/show_bug.cgi?id=101155
"Broke Qt. No way to force the damn bots to do a clean build.
I'm giving up." (Requested by kbalazs on #webkit).
Patch by Sheriff Bot <webkit.review.bot@gmail.com> on 2012-11-03
Source/WebCore:
- Target.pri:
- WebCore.pri:
- platform/qt/QtTestSupport.h: Removed.
Tools:
- DumpRenderTree/qt/DumpRenderTree.pro:
- DumpRenderTree/qt/DumpRenderTreeMain.cpp:
(main):
- DumpRenderTree/qt/DumpRenderTreeQt.cpp:
(WebCore::DumpRenderTree::open):
- DumpRenderTree/qt/QtInitializeTestFonts.cpp: Renamed from Source/WebCore/platform/qt/QtTestSupport.cpp.
(WebKit):
(WebKit::initializeTestFonts):
- DumpRenderTree/qt/QtInitializeTestFonts.h: Copied from Tools/WebKitTestRunner/InjectedBundle/qt/ActivateFontsQt.cpp.
(WebKit):
- QtTestBrowser/QtTestBrowser.pro:
- QtTestBrowser/qttestbrowser.cpp:
(LauncherApplication::handleUserOptions):
- WebKitTestRunner/InjectedBundle/Target.pri:
- WebKitTestRunner/InjectedBundle/qt/ActivateFontsQt.cpp:
(WTR::activateFonts):
- WebKitTestRunner/InjectedBundle/qt/QtInitializeTestFonts.cpp: Copied from Tools/WebKitTestRunner/InjectedBundle/qt/ActivateFontsQt.cpp.
- WebKitTestRunner/InjectedBundle/qt/QtInitializeTestFonts.h: Copied from Tools/WebKitTestRunner/InjectedBundle/qt/ActivateFontsQt.cpp.
- WebKitTestRunner/InjectedBundle/qt/TestRunnerQt.cpp:
(WTR::TestRunner::platformInitialize):
- WebKitTestRunner/Target.pri:
- WebKitTestRunner/qt/main.cpp:
(main):
- 1:52 PM Changeset in webkit [133399] by
-
- 3 edits in trunk/Source/WebCore
Speculative fix to eliminate flakiness in
css3/filters/blur-filter-page-scroll-self.html
https://bugs.webkit.org/show_bug.cgi?id=91620.
Suspicion is that a prior test is setting
window.internals.settings.setEnableCompositingForFixedPosition(true),
causing this test to be intermittely run on the GPU, giving different
pixel results depending on test order.
Reviewed by Jochen Eisinger.
Covered by css3/filters/blur-filter-page-scroll-self.html
- testing/InternalSettings.cpp:
(WebCore::InternalSettings::Backup::Backup):
(WebCore::InternalSettings::Backup::restoreTo):
- testing/InternalSettings.h:
(Backup):
- 1:48 PM Changeset in webkit [133398] by
-
- 2 edits in trunk/Source/WebCore
REGRESSION (r132858): Crash below -[DOMElement setClassName:] when called with a nil string
Reviewed by Anders Carlsson.
The changes in r132858 introduced an overload of AtomicString::add for CFStrings. However, the overload
that was introduced is not null safe.
- platform/text/cf/AtomicStringCF.cpp:
(WTF::AtomicString::add): Handle a null string by returning a null StringImpl.
- 1:36 PM Changeset in webkit [133397] by
-
- 14 edits1 move1 add3 deletes in trunk
[Qt][WK2] setPlatformStrategies always asserts after r132744
https://bugs.webkit.org/show_bug.cgi?id=100838
Reviewed by Simon Hausmann.
Source/WebCore:
The problem here is that we use QWebSettings::clearMemoryCaches, a WebKit1 API
from the injected bundle, which calls initializeWebCoreQt and it sets the platform
strategies to the one for WebKit1. We should stop using WebKit1 API's from WebKit2
code. In order to keep the behavior, this patch adds exported helpers to WebCore
that can be used from DumpRenderTree and WebKitTestRunner. This is the same idea
as WebCoreTestSupport but these helpers are specific to Qt. Technically we could
add it to the WebKit1 API for the time being, but my goal was to move in the direction
of removing the WebKit1 dependency from WebKitTestRunner. We only build the file
in non production mode.
Basically covered by all tests.
- Target.pri:
- WebCore.pri: We need to link against fontconfig (only in non-production mode) since
initializeTestFonts uses it.
- platform/qt/QtTestSupport.cpp: Added. I choose GPL license because code from qwebsettings.cpp
is also under that.
(WebKit):
(WebKit::QtTestSupport::clearMemoryCaches): This is basically a copy of QWebSettings::clearMemoryCaches
without calling initializeWebCoreQt.
(WebKit::QtTestSupport::initializeTestFonts): I moved this code here as well now that we have to expose
symbols from WebCore anyway. The advantage is that now we don't have to build it twice and we don't need
additional files to forward it from the directory of DumpRenderTree for WebKitTestRunner.
I added a call to FontCace::invalidate in the case when the font set has been changed so that it will do
the job even if we would stop clearing all caches between tests. Also moved the call to
QFontDatabase::removeAllApplicationFonts from callers to here.
- platform/qt/QtTestSupport.h:
(WebKit):
(QtTestSupport):
Tools:
Turned test runners to use the new QtTestSupport.
- DumpRenderTree/qt/DumpRenderTree.pro:
- DumpRenderTree/qt/DumpRenderTreeMain.cpp:
(main):
- DumpRenderTree/qt/DumpRenderTreeQt.cpp:
(WebCore::DumpRenderTree::open):
- QtTestBrowser/QtTestBrowser.pro:
- QtTestBrowser/qttestbrowser.cpp:
(LauncherApplication::handleUserOptions):
- WebKitTestRunner/InjectedBundle/Target.pri:
- WebKitTestRunner/InjectedBundle/qt/ActivateFontsQt.cpp:
(WTR::activateFonts):
- WebKitTestRunner/InjectedBundle/qt/QtInitializeTestFonts.cpp: Removed.
- WebKitTestRunner/InjectedBundle/qt/QtInitializeTestFonts.h: Removed.
- WebKitTestRunner/InjectedBundle/qt/InjectedBundleQt.cpp:
- WebKitTestRunner/InjectedBundle/qt/TestRunnerQt.cpp:
(WTR::TestRunner::platformInitialize): Removed the comment from here
because it was just lying, apparently two times. First, it is not incorrect
to reinitialize our font set and clear font caches, it is what the tests
expect. Second, the use of QRawFont has nothing to do with the font cache.
- WebKitTestRunner/Target.pri:
- WebKitTestRunner/qt/main.cpp:
(main):
- 9:08 AM Changeset in webkit [133396] by
-
- 17 edits2 adds in trunk
Implement HTMLFormElement#requestAutocomplete and associated events
https://bugs.webkit.org/show_bug.cgi?id=100557
Patch by Dan Beam <dbeam@chromium.org> on 2012-11-03
Reviewed by Adam Barth.
Source/WebCore:
Implements an initial version of the proposal for interactive autocomplete outlined in this email:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-October/037711.html
The goal of this patch is to allow web authors to call formElement.requestAutocomplete(); after subscribing for
autocomplete/autocompleteerror events on formElement. If the form's [autocomplete] attribute is "off" an
error will be dispatched. Otherwise, a request will be issued to the FrameLoaderClient. At the moment, the
implementation in Chrome (https://codereview.chromium.org/11270018/) will simply dispatch an error until the
UI on Chrome's side is built. Both autocomplete and autocompleteerror events will be dispatched asynchronously
after a small delay to behave consistently in all situations and implementations.
Currently this is behind the feature flag REQUEST_AUTOCOMPLETE, which is disabled.
Test: fast/forms/form-request-autocomplete.html
- dom/EventNames.h:
(WebCore):
Added autocomplete and autocompleteerror events. The autocomplete event is dispatched after a user adds more
information to a form using the future UI. This is not currently dispatched in any implementation (including Chrome)
but will be in the future. The autocompleteerror event is dispatched when the form has [autocomplete="off"] on the
node being asked for an interactive autocomplete. The user agent may also dispatch this event if it doesn't implement
this API but has turned on the feature flag, can't currently show an autocomplete UI (e.g. running headlessly or in
an HTML notification, security concerns, or any other reason it desires).
- html/HTMLAttributeNames.in:
Added onautocomplete and onautocompleteerror attributes so they can be parsed when creating form elements and used
as event listeners. For example:
<form onautocomplete="/* when autocomplete succeeds */" autocompleteerror="/* when autocomplete fails */">
- html/HTMLFormElement.cpp:
(WebCore::HTMLFormElement::HTMLFormElement):
(WebCore):
Added m_requestAutocompleteTimer (a timer that's used to dispatch events asynchronously) to the initializer list that
triggers requestAutocompleteTimerFired when it times out.
(WebCore::HTMLFormElement::requestAutocomplete):
Called when HTMLFormElement#requestAutocomplete is called from JS (also see HTMLFormElement.idl) and decides whether
to dispatch an error and exit early (in the case where autocomplete="off") or pass the request on to the
FrameLoaderClient.
(WebCore::HTMLFormElement::finishRequestAutocomplete):
Called when the request for an interactive autocomplete is finished with either a success or error result. This
causes an event to queue and fired after a 0 second delay. Events are owned by HTMLFormElement and reference the
target element (this) until fired.
(WebCore::HTMLFormElement::requestAutocompleteTimerFired):
Called when the event timer runs out to pump the queue of current events. Events are released on dispatch.
(WebCore::HTMLFormElement::parseAttribute):
Encountering onautocomplete or onautocompleteerror attributes while parsing HTMLFormElements now adds event listeners
for autocomplete an autocompleteerror events (respectively) to dispatch the value of the attribute as a script.
- html/HTMLFormElement.h:
(HTMLFormElement):
Added various methods and data members as required by the implementation.
- html/HTMLFormElement.idl:
Added the method requestAutocomplete and associated DOM event handler attributes (onautocomplete/onautocompleteerror)
to HTMLFormElement's public DOM API (unprefixed, as per Ian Hickson's advice). All are require the Conditional
REQUEST_AUTOCOMPLETE to be enabled to be activated.
- loader/EmptyClients.cpp:
(WebCore):
(WebCore::EmptyFrameLoaderClient::didRequestAutocomplete):
Added noop implementation for FrameLoader::didRequestAutocomplete.
- loader/EmptyClients.h:
(EmptyFrameLoaderClient):
Added FrameLoader::didRequestAutocomplete to EmptyFrameLoaderClient interface.
- loader/FrameLoaderClient.h:
(FrameLoaderClient):
Added noop implementation to FrameLoaderClient interface (which is implemented chromium's FrameLoaderLoaderImpl.cpp).
Source/WebKit/chromium:
Implements an initial version of the proposal for interactive autocomplete outlined in this email:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-October/037711.html
The goal of this patch is to allow web authors to call formElement.requestAutocomplete(); after subscribing for
autocomplete/autocompleteerror events on formElement. If the form's [autocomplete] attribute is "off" an
error will be dispatched. Otherwise, a request will be issued to the FrameLoaderClient. At the moment, the
implementation in Chrome (https://codereview.chromium.org/11270018/) will simply dispatch an error until the
UI on Chrome's side is built. Both autocomplete and autocompleteerror events will be dispatched asynchronously
after a small delay to behave consistently in all situations and implementations.
Currently this is behind the feature flag REQUEST_AUTOCOMPLETE, which is disabled.
Test: fast/forms/form-request-autocomplete.html
- public/WebAutofillClient.h:
(WebKit):
(WebAutofillClient):
(WebKit::WebAutofillClient::didRequestAutocomplete):
Added WebAutofillClient::didRequestAutocomplete to chrome's public WebKit interface.
- public/WebFormElement.h:
Added an enum that matches HTMLFormElement::AutocompleteResult (and added compile time assert) and a public method
(WebFormElement::finishRequestAutocomplete) to WebFormElement's public interface.
- src/AssertMatchingEnums.cpp:
Added a compile time assert to guarantee the HTMLFormElement::AutocompleteResult enum matches the
WebFormElement::AutocompleteResult enum.
- src/FrameLoaderClientImpl.cpp:
(WebKit):
(WebKit::FrameLoaderClientImpl::didRequestAutocomplete):
Implemented the added FrameLoaderClient::didRequestAutocomplete, which simply passes through to the
WebAutofillClient.
- src/FrameLoaderClientImpl.h:
(FrameLoaderClientImpl):
Implementing FrameLoaderClient::didRequestAutocomplete.
- src/WebFormElement.cpp:
(WebKit::WebFormElement::finishRequestAutocomplete):
(WebKit):
Added WebFormElement::finishRequestAutocomplete to allow chromium's renderer a public API to call to finish the
autocomplete request on a WebFormElement.
LayoutTests:
Adds tests for an initial implementation of the proposal for interactive autocomplete outlined in this email:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-October/037711.html
The goal of this patch is to allow web authors to call formElement.requestAutocomplete(); after subscribing
for autocomplete/autocompleteerror events on formElement. If the form's [autocomplete] attribute is "off" an
error will be dispatched. Otherwise, a request will be issued to the FrameLoaderClient. At the moment, the
implementation in Chrome (https://codereview.chromium.org/11270018/) will simply dispatch an error until the
UI on Chrome's side is built. Both autocomplete and autocompleteerror events will be dispatched asynchronously
after a small delay to behave consistently in all situations and implementations.
Currently the implementation is behind the feature flag REQUEST_AUTOCOMPLETE, which is disabled, so the test
is expected to fail. This test verifies that currently no client implements this method on HTMLFormElement
(HTMLFormElement#requestAutocomplete) and returns. When the chrome-side lands I'll add a success case in
LayoutTests/platform/chromium/fast/forms/ with the expected successful results.
- fast/forms/form-request-autocomplete-expected.txt: Added.
- fast/forms/form-request-autocomplete.html: Added.
- 8:32 AM Changeset in webkit [133395] by
-
- 5 edits2 adds in trunk
Web Inspector: %d, %i, and %f log formatters have same result
https://bugs.webkit.org/show_bug.cgi?id=101148
Reviewed by Alexander Pavlov.
Source/WebCore:
Added separate formatters for %f, %i, %d and %s.
Test: inspector/console/console-message-format.html
- inspector/front-end/ConsoleMessage.js:
(WebInspector.ConsoleMessageImpl.prototype.stringFormatter):
(WebInspector.ConsoleMessageImpl.prototype.floatFormatter):
(WebInspector.ConsoleMessageImpl.prototype.integerFormatter):
LayoutTests:
- inspector/console/console-format-expected.txt:
- inspector/console/console-format.html:
- inspector/console/console-message-format-expected.txt: Added.
- inspector/console/console-message-format.html: Added.
- 4:55 AM Changeset in webkit [133394] by
-
- 7 edits in trunk/Source/WebCore
Decouple Attr logic from ElementAttributeData.
<http://webkit.org/b/101126>
Reviewed by Antti Koivisto.
Move all logic dealing with Attr DOM nodes from ElementAttributeData to Element.
This makes more sense since an Attr is tied to a single Element, but an ElementAttributeData
can be shared by any number of Elements at a given time.
Also updated naming convention from just "Attr" to "Attr node" in the code I was touching.
"Attr" is way too generic, and has been historically confused with WebCore::Attribute a lot.
- dom/Element.h:
- dom/ElementAttributeData.h:
- dom/Element.cpp:
(WebCore::attrNodeListMap):
(WebCore::attrNodeListForElement):
(WebCore::ensureAttrNodeListForElement):
(WebCore::removeAttrNodeListForElement):
(WebCore::findAttrNodeInList):
(WebCore::Element::~Element):
(WebCore::Element::detachAttribute):
(WebCore::Element::setAttributeNode):
(WebCore::Element::removeAttributeInternal):
(WebCore::Element::getAttributeNode):
(WebCore::Element::getAttributeNodeNS):
(WebCore::Element::normalizeAttributes):
(WebCore::Element::attrIfExists):
(WebCore::Element::ensureAttr):
(WebCore::Element::detachAttrNodeFromElementWithValue):
(WebCore::Element::detachAllAttrNodesFromElement):
(WebCore::Element::cloneAttributesFromElement):
Move everything Attr-related into Element.cpp while simplifying some loops and remove
conditions that are no longer needed as they used to depend on having an attributeData().
- dom/Node.h:
(WebCore::Node::hasSyntheticAttrChildNodes):
(WebCore::Node::setHasSyntheticAttrChildNodes):
Renamed the hasAttrList() node flag to hasSyntheticAttrChildNodes().
- dom/Attr.cpp:
(WebCore::Attr::detachFromElementWithValue):
Remove awkward indirection and let the call site deal with removing the Attr node from
the Element's list of Attr nodes.
- dom/ElementAttributeData.cpp:
(WebCore::ElementAttributeData::clearAttributes):
Remove now-unused Element* argument.
- 4:36 AM Changeset in webkit [133393] by
-
- 4 edits in trunk/Source
REGRESSION (r132014-r132047): Webkit Inspector Window docking broken
https://bugs.webkit.org/show_bug.cgi?id=101125
Reviewed by Vsevolod Vlasov.
Source/WebCore:
Added "bottom" as default docked state.
- inspector/front-end/DockController.js:
(WebInspector.DockController):
Source/WebKit2:
Migrated from ?docked= to ?dockSide= format.
- UIProcess/WebInspectorProxy.cpp:
(WebKit::WebInspectorProxy::createInspectorPage):
