Timeline
May 13, 2007:
- 10:13 PM Changeset in webkit [21449] by
-
- 5 edits in branches/wx-port-alpha/trunk
Restore the Windows build after WEBKITOUTPUTDIR changes, and also copy over dependency dlls to product dir so that testkjs and the sample app won't complain about missing dlls.
- 9:45 PM Changeset in webkit [21448] by
-
- 4 edits2 adds2 deletes in trunk
Reviewed by Darin.
http://bugs.webkit.org/show_bug.cgi?id=13690
JavaScript Form Validation issue on Banco do Brasil site
Test: fast/forms/input-setvalue-selection.html
- html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::setValue): In other browsers, changing textInput.value always moves the insertion point past the text. In 10.4.9 WebKit, this only worked for inactive controls, and it never worked in ToT.
- 11:43 AM Changeset in webkit [23359] by
-
- 2 edits in branches/WindowsMerge/WebCore
Requested by Hyatt.
- internal part of http://bugs.webkit.org/show_bug.cgi?id=13529 DOM3 keyIdentifier text is incorrect
- platform/win/KeyEventWin.cpp: (WebCore::keyIdentifierForWindowsKeyCode): Use 4 digits for "U+" stuff.
- 8:28 AM Changeset in webkit [21447] by
-
- 5 edits in trunk/WebCore
Reviewed by Mitz
Since HTMLInputElements register themselves with their Document for special handling, if their document
ever changes then bad things can happen.
Unfortunately, with adoptNode, the document can change. This has been a long standing crasher with all
input fields but was given recent high visibility by r21430
The solution is to add functionality for a Node to react to its owner document changing via a pair of
virtual callbacks. Then we can tap into those callbacks in HTMLInputElement.
No layout test possible until http://bugs.webkit.org/show_bug.cgi?id=13672 is resolved
- dom/Node.cpp: (WebCore::Node::setDocument): Call willMoveToNewOwnerDocument and didMoveToNewOwnerDocument
- dom/Node.h: (WebCore::Node::willMoveToNewOwnerDocument): Virtual callback to a node for before an owner document change (WebCore::Node::didMoveToNewOwnerDocument): Virtual callback to a node for after an owner document change
- html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::~HTMLInputElement): Unconditionally unregister both for both form state and the cache restoration callback (WebCore::HTMLInputElement::setInputType): Change registration with the document only if we're in one (WebCore::HTMLInputElement::attach): Don't bother registering for the callback here - that will be handled by setInputType() or by a change in owner document (WebCore::HTMLInputElement::willMoveToNewOwnerDocument): Unregister with the old owner document (WebCore::HTMLInputElement::didMoveToNewOwnerDocument): Register with the new owner document
- html/HTMLInputElement.h:
- 7:05 AM Changeset in webkit [21446] by
-
- 2 edits in trunk/WebCore
- platform/mac/TextBreakIteratorInternalICUMac.mm: Fix comment typo.
- 7:00 AM Changeset in webkit [21445] by
-
- 21 edits in trunk
Reviewed by Darin.
http://bugs.webkit.org/show_bug.cgi?id=13529
DOM3 keyIdentifier text is incorrect
Use 4 digits for the Unicode based key identifiers.
- 6:21 AM Changeset in webkit [21444] by
-
- 2 edits in trunk/WebKit
- one more retain/release for a tiny bit more robustness
- WebView/WebPDFView.mm: (-[WebPDFView _updatePreferences:]): [prefs release] (-[WebPDFView _updatePreferencesSoon]): [prefs retain]
- 6:16 AM Changeset in webkit [21443] by
-
- 3 edits in trunk/WebKit
Reviewed by Geoff.
- fix <rdar://problem/5188400> Webkit crashes going back from PDF at perl.org site
- WebView/WebPDFView.h: Replace _updatePreferencesTimer with _willUpdatePreferencesSoon BOOL. Also remove unneeded @public that gives other classes access to our dataSource member.
- WebView/WebPDFView.mm: Rearrange top of file a bit, remove forward declaration of the _cancelUpdatePreferencesTimer method. (-[WebPDFView dealloc]): Removed call to _cancelUpdatePreferencesTimer. (-[WebPDFView _updatePreferencesNow:]): Added WebPreferences parameter. This sidesteps problems where the dataSource is no longer present by not looking at the dataSource field at all. Also removed the call to _cancelUpdatePreferencesTimer, added code to set _willUpdatePreferencesSoon to NO and added a release to balance a retain I did in _updatePreferencesSoon. (-[WebPDFView _updatePreferencesSoon]): Changed to use performSelectorAfterDelay instead of an NSTimer. Pass in the preferences object as a parameter, since we might not be able to get to the dataSource when the timer fires.
- 5:55 AM Changeset in webkit [21442] by
-
- 2 edits in trunk/WebCore
Reviewed by Antti.
- fix <rdar://problem/5174903> Safari crashes opening the attached webarchive (made by OmniWeb)
- loader/icon/IconLoader.cpp: (WebCore::IconLoader::didReceiveResponse): Check ResourceHandle for nil before calling url() on it. (WebCore::IconLoader::didFail): Ditto. (WebCore::IconLoader::didFinishLoading): Ditto.
- 12:25 AM Changeset in webkit [21441] by
-
- 6 edits in trunk/WebCore
Reviewed by Oliver.
Cleanup, get rid of the SVGStyledElement::view() call.
May 12, 2007:
- 11:02 PM Changeset in webkit [21440] by
-
- 4 adds in trunk/LayoutTests/fast/invalid
Add layout tests for residual style fix.
- 11:01 PM Changeset in webkit [21439] by
-
- 2 edits in trunk/WebCore
Reviewed by Hyatt.
- fix http://bugs.webkit.org/show_bug.cgi?id=13680 Incomplete repaint of focus ring around continuation
Test: fast/repaint/continuation-after-outline.html
- rendering/RenderFlow.cpp: (WebCore::RenderFlow::absoluteClippedOverflowRect):
- 10:50 PM Changeset in webkit [21438] by
-
- 3 edits4 adds in trunk
LayoutTests:
Reviewed by Hyatt.
- repaint test for http://bugs.webkit.org/show_bug.cgi?id=13680 Incomplete repaint of focus ring around continuation
- fast/repaint/continuation-after-outline-expected.checksum: Added.
- fast/repaint/continuation-after-outline-expected.png: Added.
- fast/repaint/continuation-after-outline-expected.txt: Added.
- fast/repaint/continuation-after-outline.html: Added.
WebCore:
Reviewed by Hyatt.
- fix http://bugs.webkit.org/show_bug.cgi?id=13680 Incomplete repaint of focus ring around continuation
Test: fast/repaint/continuation-after-outline.html
- rendering/RenderFlow.cpp: (WebCore::RenderFlow::absoluteClippedOverflowRect):
- 10:26 PM Applications using WebKit edited by
- Added Midori web browser. (diff)
- 10:21 PM Changeset in webkit [23358] by
-
- 2 edits in branches/WindowsMerge/WebCore
2007-05-12 Oliver Hunt <oliver@apple.com>
rs=hyatt.
Stubs to prevent build bustage
- platform/win/DragDataWin.cpp: (WebCore::DragData::containsFiles): (WebCore::DragData::asFilenames):
- 10:15 PM Changeset in webkit [21437] by
-
- 13 edits2 adds in trunk
2007-05-12 Oliver Hunt <oliver@apple.com>
LayoutTests:
Reviewed by Hyatt.
Add test to verify files can be dragged to <input type="file">
- fast/forms/dragging-to-file-input-expected.txt: Added.
- fast/forms/dragging-to-file-input.html: Added.
WebCore:
Reviewed by Hyatt.
<rdar://problem/4728842> Can't drag-and-drop files onto <input type="file">
This patch allows a file to be dropped on to a file input field. There
are a few changes for data handling and a few to allow the data to be
threaded to the appropriate places.
- page/DragController.cpp: (WebCore::asFileInput):
When dropping a file onto a file input we may mouse over either
the element itself, or the contained button element. This method
returns the base element for the file input in either of these
cases.
(WebCore::DragController::tryDocumentDrag):
Don't try to set the drag caret to a file input.
(WebCore::DragController::concludeDrag):
Handle dropping onto a file input element.
(WebCore::DragController::canProcessDrag):
We can now process a file being dragged onto a file input element.
- platform/DragData.h:
New accessors
- platform/gdk/DragDataGdk.cpp: (WebCore::DragData::containsFiles): (WebCore::DragData::asFilenames):
Link stubs.
- platform/mac/DragDataMac.mm: (WebCore::DragData::containsFiles): (WebCore::DragData::asFilenames):
Implement new accessors
(WebCore::DragData::containsCompatibleContent):
Update containsCompatibleContent to allow standalone files.
- platform/qt/DragDataQt.cpp: (WebCore::DragData::containsFiles): (WebCore::DragData::asFilenames):
Link stubs
- rendering/RenderFileUploadControl.cpp: (WebCore::RenderFileUploadControl::receiveDroppedFile):
- rendering/RenderFileUploadControl.h:
For security reasons we don't have an api to allow us to set
a value directly on a file input -- attempts to do so are
blocked. By adding a method to set the target through the
render we bypass such restrictions, and ensure the renderer
is updated correctly.
WebKitTools:
Reviewed by Hyatt.
Add new api to DRT to allow us to test a file being dragged
onto <input type="file">
- DumpRenderTree/DumpRenderTree.h:
- DumpRenderTree/DumpRenderTree.m: (+[LayoutTestController isSelectorExcludedFromWebScript:]): (-[LayoutTestController addFileToPasteboardOnDrag]): (runTest):
- DumpRenderTree/UIDelegate.m: (-[UIDelegate webView:dragImage:at:offset:event:pasteboard:source:slideBack:forView:]):
- 7:31 PM Changeset in webkit [21436] by
-
- 4 edits4 adds in trunk
LayoutTests:
Reviewed by Hyatt.
- pixel test for http://bugs.webkit.org/show_bug.cgi?id=13695 REGRESSION (r21387): Replaced elements' highlight rects are wrongly positioned
- fast/replaced/selection-rect-expected.checksum: Added.
- fast/replaced/selection-rect-expected.png: Added.
- fast/replaced/selection-rect-expected.txt: Added.
- fast/replaced/selection-rect.html: Added.
WebCore:
Reviewed by Hyatt.
- fix http://bugs.webkit.org/show_bug.cgi?id=13695 REGRESSION (r21387): Replaced elements' highlight rects are wrongly positioned
Test: fast/replaced/selection-rect.html
Also fixes the same problem with list markers, covered by existing test
fast/lists/markers-in-selection.html.
- rendering/RenderListMarker.cpp: (WebCore::RenderListMarker::selectionRect):
- rendering/RenderReplaced.cpp: (WebCore::RenderReplaced::selectionRect):
- 7:12 PM Changeset in webkit [21435] by
-
- 3 edits4 adds in trunk
LayoutTests:
Reviewed by Darin.
- repaint test for http://bugs.webkit.org/show_bug.cgi?id=13685 REGRESSION (r21368-r21388): Highlighting text in scrolled textareas behaves oddly
- fast/repaint/text-selection-rect-in-overflow-expected.checksum: Added.
- fast/repaint/text-selection-rect-in-overflow-expected.png: Added.
- fast/repaint/text-selection-rect-in-overflow-expected.txt: Added.
- fast/repaint/text-selection-rect-in-overflow.html: Added.
WebCore:
Reviewed by Darin.
- fix http://bugs.webkit.org/show_bug.cgi?id=13685 REGRESSION (r21368-r21388): Highlighting text in scrolled textareas behaves oddly
Test: fast/repaint/text-selection-rect-in-overflow.html
- rendering/RenderText.cpp: (WebCore::RenderText::selectionRect):
- 5:50 PM Changeset in webkit [21434] by
-
- 7 edits in branches/wx-port-alpha/trunk
Have Bakefile internally refer to WEBKITOUTPUTDIR and WEBKIT_ROOT using different names to avoid collisions when those are defined as environment variables on the user's machine.
- 5:39 PM Changeset in webkit [21433] by
-
- 1 edit in branches/wx-port-alpha/trunk/WebKit/wx/WebView.cpp
Don't schedule a relayout, that triggers the if (root->needsLayout()) code path in FrameView::layout(). See #13455 for why this is a problem. Also, if frameView->needsLayout() is true, make sure to layout before painting rather than bailing out of the paint event.
- 3:24 PM Changeset in webkit [21432] by
-
- 3 edits in trunk/WebKitQt
Reviewed by Rob Buis.
- call Frame::init as needed - this prevents crashes but pages don't appear.
- Api/qwebframe.cpp: (QWebFramePrivate::init):
- WebKitPart/WebKitPart.cpp: (WebKitPart::initView):
- 2:56 PM Changeset in webkit [21431] by
-
- 2 edits in trunk/WebCore
Rubber stamped by Mitz
- html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::attach): unregister->register - I screwed this one up in last minute renaming before committing :(
- 2:22 PM Changeset in webkit [21430] by
-
- 12 edits in trunk/WebCore
Reviewed by Darin and Geoff
Fix for http://bugs.webkit.org/show_bug.cgi?id=13630
and
<rdar://problem/4873628>
Back/Forward cache should work with pages with login fields.
First change is to relocate the "useSecureKeyboardEntry" flag to the document. This lets
it persist through page cache transitions and it is truly a per-document concept more than
per-frame anyways since its the document that has a password field, not the frame.
Second change is to introduce the concept of an Element getting a "didRestoreFromCache()" callback.
The idea is for elements to register with the document if they need work to be done when the
page comes out of the back/forward cache. Currently the only client of this service is
HTMLInputElements that are input type == PASSWORD. Such an element's implementation for this
method is to call reset()
Finally, after a page is restored from the cache we have the document send the didRestoreFromCache()
callback to its registered Elements. The whole design is to clear the password fields after
restoring the page instead of when caching the page because we want to defer work for the common
case - there shouldn't be extra work here just to navigate away from a page when the common case
is that you'll never go back!
No layout tests possible until http://bugs.webkit.org/show_bug.cgi?id=13672 is resolved
- dom/Document.cpp: (WebCore::Document::Document): (WebCore::Document::registerForDidRestoreFromCacheCallback): Add an Element to the special page-restoration callback list (WebCore::Document::unregisterForDidRestoreFromCacheCallback): Remove such an element (WebCore::Document::didRestoreFromCache): Called by FrameLoader - dispatch to all the registered elements (WebCore::Document::setUseSecureKeyboardEntryWhenActive): Set the local flag and call updateSecureKeyboardEntryIfActive on the Frame (WebCore::Document::useSecureKeyboardEntryWhenActive): Return the flag
- dom/Document.h: (WebCore::Document::unregisterFormElementWithState): Renamed
- dom/Element.h: (WebCore::Element::didRestoreFromCache): Added virtual base method
- html/HTMLInputElement.cpp: (WebCore::HTMLInputElement::~HTMLInputElement): Deregister from the document if inputType == PASSWORD (WebCore::HTMLInputElement::dispatchFocusEvent): Set the flag on the document, not the frame (WebCore::HTMLInputElement::dispatchBlurEvent): Ditto (WebCore::HTMLInputElement::setInputType): If changing to/from PASSWORD, register/deregister in the document accordingly (WebCore::HTMLInputElement::attach): Call registerForDidRestoreFromCacheCallback(this) instead of passwordFieldAdded() (WebCore::HTMLInputElement::didRestoreFromCache): Call reset();
- html/HTMLInputElement.h:
- html/HTMLSelectElement.cpp: (WebCore::HTMLSelectElement::~HTMLSelectElement): Renamed deregisterFormElementWithState to unregisterFormElementWithState
- html/HTMLTextAreaElement.cpp: (WebCore::HTMLTextAreaElement::~HTMLTextAreaElement): Ditto
- loader/FrameLoader.cpp: (WebCore::FrameLoader::canCachePage): Remove the check for password fields - they're allowed now! (WebCore::FrameLoader::opened): Tell the document to dispatch to the registered elements (WebCore::FrameLoader::saveDocumentState): Remove the check for password fields. Turns out that when we grab a copy a the form state we're only copying the state of form elements that are registered with the Document - and that set explicitly excludes Password elements
- page/Frame.cpp: (WebCore::Frame::setDocument): If the frame is active, set the setUseSecureKeyboardEntry based on the setting contained in the new document (WebCore::Frame::updateSecureKeyboardEntryIfActive): Notification for the secure entry flag changing - if the Frame is active, then update to the new setting from the document (WebCore::Frame::setIsActive): Grab the useSecureKeyboardEntry flag from the document instead of FramePrivate (WebCore::FramePrivate::FramePrivate):
- page/Frame.h:
- page/FramePrivate.h:
- 2:18 PM Changeset in webkit [21429] by
-
- 28 edits4 adds in trunk/LayoutTests/fast/invalid
Update existing invalid tests and add new test for 12740.
- 2:15 PM Changeset in webkit [21428] by
-
- 2 edits in trunk/WebCore
Fix for bug 12740, bmw.com doesn't work. We were missing a rule that is covered by the HTML5
parsing spec. A <table> encountered while inside stray table content should close up the
table responsible for the stray content and start the new table as a sibling of the first.
Reviewed by mjs
fast/invalid/table-inside-stray-table-content.html
- 1:35 AM Changeset in webkit [21427] by
-
- 2 edits in trunk/WebCore
2007-05-12 Eric Seidel <eric@webkit.org>
Reviewed by mjs.
Crash starting Safari with JavaScript disabled.
http://bugs.webkit.org/show_bug.cgi?id=13691
Test: none possible.
- page/mac/FrameMac.mm: (WebCore::Frame::cleanupPlatformScriptObjects): NULL check d->m_script