Context Navigation

← Previous Period
Next Period →

Timeline

May 27, 2013:

11:57 PM Changeset in webkit [150788] by Patrick Gansterer

3 edits in trunk/Source/WebCore

Build fix for WinCE after r150772.

platform/win/ClipboardWin.cpp:

(WebCore):

platform/win/PasteboardWin.cpp:

(WebCore::Pasteboard::readFilenames):
(WebCore):

11:48 PM Changeset in webkit [150787] by gyuyoung.kim@samsung.com

3 edits in trunk/Source/WebKit2

[EFL][WK2] Remove unneeded WebCore namespace use in ewk
https://bugs.webkit.org/show_bug.cgi?id=116707

Reviewed by Christophe Dumez.

UIProcess/API/efl/ewk_security_origin.cpp: Remove "using namespace WebCore".
UIProcess/API/efl/ewk_text_checker.cpp: ditto.

11:31 PM Changeset in webkit [150786] by Patrick Gansterer

2 edits in trunk/Source/WTF

Use correct stack size on Solaris and OpenBSD
https://bugs.webkit.org/show_bug.cgi?id=114978

Recommit after wrong rollout in r150621.

wtf/StackBounds.cpp:

(WTF):
(WTF::StackBounds::initialize):

5:02 PM Changeset in webkit [150785] by jonlee@apple.com

14 edits
1 add
1 delete in trunk

[WK2] Notifications clobber each other with multiple processes
https://bugs.webkit.org/show_bug.cgi?id=116428
<rdar://problem/13935191>

Reviewed by Darin Adler.

ManualTests/notification-in-multiple-windows.html: Added.

Source/WebKit2:

With multiple processes, the notification IDs, when passed up to the UI process, can clobber
each other. To fix this, we need to maintain a global map of notification IDs. This map is
keyed by its own unique notification ID, and maps to a pair containing the web page ID and that
web page's ID for the notification.

Now that we maintain groups of notifications based on the web page, we no longer send IPC messages
from WebNotificationManager to WebNotificationManagerProxy; instead we send messages to the
WebPageProxy. This removes the need for WebNotificationManagerProxy to be a message receiver.

When a page closes, all of the web notifications are cleared out. However, by the time the
WebPage::close() is called, the connection between WebPage and WebPageProxy is destroyed. Since
the WebPage is told to close from the UI process anyway, we clear out the notifications separately,
instead of waiting for a message from the WebPage.

UIProcess/Notifications/WebNotificationManagerProxy.h: Update to take into account the

notification's web page. Remove inheritance of CoreIPC::MessageReceiver. Expose the original message
handlers as public functions, since they will be called from WebPageProxy. Add a new map that
associates a global ID with a notification ID that came from a web page.

There are now two flavors of clearNotifications(). One clears out all notifications associated

with a web page. This is called when the page is closed. The other clears out a subset of
notifications associated with a web page. This is called when notifications associated with a sub-frame
is closed.

UIProcess/Notifications/WebNotificationManagerProxy.messages.in: Removed. All messages from

the web process go to WebPageProxy now.

UIProcess/Notifications/WebNotificationManagerProxy.cpp: Update to take into account the

notification's web page.

(WebKit::generateGlobalNotificationID): The manager proxy now maintains its own global notification
ID generator.
(WebKit::WebNotificationManagerProxy::WebNotificationManagerProxy): The proxy is no longer a
message receiver. Remove code that registers it as such.

(WebKit::WebNotificationManagerProxy::show): Refactor to differentiate between the notification ID
that came from the web process, and the global notification ID the proxy maintains. Add the mapping
from the global ID to the (web page ID, notification ID) pair.
(WebKit::WebNotificationManagerProxy::cancel): Refactor to take into consideration the web page.
(WebKit::WebNotificationManagerProxy::didDestroyNotification): Refactor to take into consideration
the web page. Fixes a leak where we did not remove the item from the maps. This function is called
from the web process, when the ScriptExecutionContext is destroyed, so we remove it from our maps
before we pass the message along to the provider.

Helper functions that evaluate when a given notification in the map matches the desired parameters.
(WebKit::pageIDsMatch): The notification is associated with the provided page.
(WebKit::pageAndNotificationIDsMatch): The notification is associated with the provided page and is
contained within the list of provided notifications.

(WebKit::WebNotificationManagerProxy::clearNotifications): Changed to only remove notifications
associated with the provided web page, and could include a specific list of notifications. This latter
situation occurs if notifications were associated with an iframe, and that iframe was removed.
There is an O(n) walk that could be make more efficient using another hash map, but that's overhead
for a map that should be small in size anyway.

(WebKit::WebNotificationManagerProxy::providerDidShowNotification): Refactor to take into
consideration the web page.
(WebKit::WebNotificationManagerProxy::providerDidClickNotification): Refactor to take into
consideration the web page.
(WebKit::WebNotificationManagerProxy::providerDidCloseNotifications): Now we need to comb through
the list of global IDs and put them in buckets based on the notification's web pages. After that
is done we can send the DidCloseNotifications() to those pages' processes. There is a possible
extra optimization here where we group based on the page's process instead, to reduce the number
of messages sent to processes.

UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::close): When a web page is closed, we clear the notifications associated
with the page.
(WebKit::WebPageProxy::cancelNotification): Forward call to WebNotificationManagerProxy.
(WebKit::WebPageProxy::clearNotifications): Ditto.
(WebKit::WebPageProxy::didDestroyNotification): Ditto.

UIProcess/WebPageProxy.h:
UIProcess/WebPageProxy.messages.in:

WebProcess/Notifications/NotificationPermissionRequestManager.cpp:
WebProcess/Notifications/WebNotificationManager.cpp:

(WebKit::WebNotificationManager::cancel):
(WebKit::WebNotificationManager::clearNotifications):
(WebKit::WebNotificationManager::didDestroyNotification):

WebProcess/Notifications/NotificationPermissionRequestManager.cpp: Remove extraneous include.

CMakeLists.txt: Remove WebNotificationManagerProxy.messages.in and related files.
DerivedSources.pri: Ditto.
DerivedSources.make: Ditto.
GNUmakefile.list.am: Ditto.
WebKit2.xcodeproj/project.pbxproj: Ditto.

4:55 PM Changeset in webkit [150784] by Darin Adler

2 edits in trunk/Source/WebCore

Fix typo that broke the build.

4:53 PM Changeset in webkit [150783] by Darin Adler

4 edits in trunk/Source/WebCore

Move hasNonEmptyBoundingBox from Node to HTMLAnchorElement
https://bugs.webkit.org/show_bug.cgi?id=116842

Reviewed by Antti Koivisto.

dom/Node.cpp: Removed hasNonEmptyBoundingBox.
dom/Node.h: Ditto.

html/HTMLAnchorElement.cpp:

(WebCore::HTMLAnchorElement::isMouseFocusable): Fixed #if to be more readable and
added more-explicit clearer comments. No behavior change.
(WebCore::hasNonEmptyBox): Added. Has the same code that was in
Node::hasNonEmptyBoundingBox with some additional comments.
(WebCore::HTMLAnchorElement::isKeyboardFocusable): Call hasNonEmptyBox.

4:40 PM Changeset in webkit [150782] by Darin Adler

11 edits in trunk/Source/WebCore

Move isBlockFlowElement and related functions out of the Node class into editing code
https://bugs.webkit.org/show_bug.cgi?id=116846

Reviewed by Antti Koivisto.

dom/Node.cpp: Removed isBlockFlowElement, enclosingBlockFlowElement, and

inSameContainingBlockFlowElement. These are all editing functions that don't
belong in the Node class, and mostly-deprecated ones to boot.

dom/Node.h: Ditto.

dom/Position.cpp:

(WebCore::inSameEnclosingBlockFlowElement): Added. This editing-specific function
is used only here, so put it here.
(WebCore::Position::rendersInDifferentPosition): Updated to call new function above.
(WebCore::Position::leadingWhitespacePosition): Ditto.

editing/InsertLineBreakCommand.cpp:

(WebCore::InsertLineBreakCommand::insertNodeAfterPosition): Use
deprecatedEnclosingBlockFlowElement at its new location.
(WebCore::InsertLineBreakCommand::insertNodeBeforePosition): Ditto.

editing/InsertListCommand.cpp:

(WebCore::InsertListCommand::doApplyForSingleParagraph): use
isBlockFlowElement at its new location.

editing/ReplaceSelectionCommand.cpp:

(WebCore::enclosingInline): Ditto.

editing/VisiblePosition.cpp:

(WebCore::VisiblePosition::canonicalPosition): Use deprecatedEnclosingBlockFlowElement
at its new location.
(WebCore::enclosingBlockFlowElement): Ditto. Also added FIXME.

editing/VisibleSelection.cpp:

(WebCore::makeSearchRange): Ditto.

editing/htmlediting.cpp:

(WebCore::isBlockFlowElement): Added. Same as the Node::isBlockFlowElement
function, but here because this is an editing function, not suitable as a Node member.
(WebCore::deprecatedEnclosingBlockFlowElement): Ditto. Added "deprecated" to the name
since the Node member function had a comment saying it was deprecated. Also changed so
it tolerates a 0 for an argument, which made it easier for one caller.

editing/htmlediting.h: Added the two new functions.

3:31 PM Changeset in webkit [150781] by benjamin@webkit.org

1 edit
3 adds in trunk/PerformanceTests

Add a balanced benchmark for QuerySelector
https://bugs.webkit.org/show_bug.cgi?id=116811

Reviewed by Sam Weinig.

The goal of this benchmark is to have an overview of querySelector as typically used
by webpages.

It uses queries similar to what is used by popular websites and applies somewhat
similar weighting for each type of query.

The tree used for the queries is intentionally kept simple to ensure we measure QuerySelector
a not purely the overhead of traversal.

CSS/QuerySelector.html: Added.
CSS/resources/query-selector.html: Added.

3:09 PM Changeset in webkit [150780] by fpizlo@apple.com

4 edits
9 adds in branches/dfgFourthTier

fourthTier: DFG ArithMod should have the !nodeUsedAsNumber optimizations that ArithDiv has
https://bugs.webkit.org/show_bug.cgi?id=116841

Reviewed by Mark Hahnenberg.

Source/JavaScriptCore:

dfg/DFGSpeculativeJIT.cpp:

(JSC::DFG::SpeculativeJIT::compileArithMod):

LayoutTests:

fast/js/dfg-mod-by-neg1-and-then-or-zero-interesting-reg-alloc-expected.txt: Added.
fast/js/dfg-mod-by-neg1-and-then-or-zero-interesting-reg-alloc.html: Added.
fast/js/dfg-mod-by-zero-and-then-or-zero-interesting-reg-alloc-expected.txt: Added.
fast/js/dfg-mod-by-zero-and-then-or-zero-interesting-reg-alloc.html: Added.
fast/js/dfg-mod-neg2tothe31-by-one-and-then-or-zero-with-interesting-reg-alloc-expected.txt: Added.
fast/js/dfg-mod-neg2tothe31-by-one-and-then-or-zero-with-interesting-reg-alloc.html: Added.
fast/js/jsc-test-list:
fast/js/script-tests/dfg-mod-by-neg1-and-then-or-zero-interesting-reg-alloc.js: Added.

(foo):

fast/js/script-tests/dfg-mod-by-zero-and-then-or-zero-interesting-reg-alloc.js: Added.

(foo):

fast/js/script-tests/dfg-mod-neg2tothe31-by-one-and-then-or-zero-with-interesting-reg-alloc.js: Added.

(foo):

2:59 PM Changeset in webkit [150779] by commit-queue@webkit.org

3 edits in trunk/Source/WebKit/blackberry

[BlackBerry] Clear supression flag when caret changes aren't propogated through
https://bugs.webkit.org/show_bug.cgi?id=116840

Patch by Nima Ghanavatian <nghanavatian@blackberry.com> on 2013-05-27
Reviewed by Rob Buis.

Internally reviewed by Mike Fenton.

PR339965
We set and clear the flag upon every use. This leaves us vulnerable if

midway through processing the selection change event is dismissed and
we don't receive a TouchRelease event

One example of this is while dragging the FCC handle we start typing. To
safeguard against this, if the process change guard is set during a
selection change event, we send out to clear the flag status before returning.

Api/WebPageClient.h:
WebKitSupport/InputHandler.cpp:

(BlackBerry::WebKit::InputHandler::selectionChanged):

2:11 PM Changeset in webkit [150778] by commit-queue@webkit.org

2 edits in trunk/Source/WebCore

Add guard around paintForFixedRootBackground
https://bugs.webkit.org/show_bug.cgi?id=116754

Patch by Seokju Kwon <Seokju Kwon> on 2013-05-27
Reviewed by Simon Fraser.

paintForFixedRootBackground is only used when ACCELERATED_COMPOSITING is enabled.

No new tests, no behavior change.

rendering/RenderLayer.cpp:

(WebCore):

2:00 PM Changeset in webkit [150777] by commit-queue@webkit.org

2 edits in trunk/Source/WebCore

Remove a leftover Pagepoup from PickerIndicatorElement.h
https://bugs.webkit.org/show_bug.cgi?id=116801

Patch by Seokju Kwon <Seokju Kwon> on 2013-05-27
Reviewed by Anders Carlsson.

No new tests, no behavior change.

html/shadow/PickerIndicatorElement.h:

(WebCore):

1:58 PM Changeset in webkit [150776] by Claudio Saavedra

5 edits in trunk

[CSS] -webkit-var prefix is case-sensitive
https://bugs.webkit.org/show_bug.cgi?id=116829

Reviewed by Darin Adler.

Source/WebCore:

Tests: Added case to fast/css/variables/case-sensitive.html

css/CSSParser.cpp:

(WebCore::isEqualToCSSCaseSensitiveIdentifier): Add variant to
IsEqualToCSSIdentifier that respects case-sensitivity.
(WebCore::CSSParser::realLex): Use the above method for CSS
variable declarations.

LayoutTests:

fast/css/variables/case-sensitive.html: Add a

check for case-sensitiveness of the prefix of
variable declarations.

fast/css/variables/case-sensitive-expected.html: Update.

1:39 PM WebKitGTK/2.0.x edited by zandobersek@gmail.com

(diff)

1:07 PM Changeset in webkit [150775] by commit-queue@webkit.org

3 edits in trunk/Source/WebCore

drop-shadow filter with overflow:hidden child misbehaves.
https://bugs.webkit.org/show_bug.cgi?id=109783

Patch by Zalan Bujtas <Alan Bujtas> on 2013-05-27
Reviewed by Simon Fraser.

Applying CSS filters only to the scrollbar rect leaves rendering
artefacts. Filters should skip such partial repaints.

Tests: Test framework uses mock theme for scrollbars. Such scrollbars do not
initiate partial repaints.

rendering/RenderLayer.cpp:

(WebCore::RenderLayer::setupFilters):
(WebCore::RenderLayer::paintLayerContents):

rendering/RenderLayer.h:

(RenderLayer):

1:04 PM Changeset in webkit [150774] by timothy_horton@apple.com

2 edits in trunk/Source/WebKit2

Unreviewed build fix take 2.

WebProcess/Plugins/PDF/PDFPlugin.mm:

12:58 PM Changeset in webkit [150773] by timothy_horton@apple.com

2 edits in trunk/Source/WebKit2

Unreviewed build fix.

WebProcess/Plugins/PDF/PDFPlugin.mm:

12:51 PM Changeset in webkit [150772] by commit-queue@webkit.org

9 edits
1 delete in trunk/Source

Move Windows port off legacy clipboard.
https://bugs.webkit.org/show_bug.cgi?id=116258

Patch by Xueqing Huang <huangxueqing@baidu.com> on 2013-05-27
Reviewed by Darin Adler.

Source/WebCore:

Clipboard refactor, no new tests.

dom/Clipboard.h:
page/win/EventHandlerWin.cpp:

(WebCore::EventHandler::createDraggingClipboard): Create Clipboard instead of ClipboardWin.

platform/Pasteboard.h:

(WebCore::Pasteboard::dataObject): Get IDataObject by Clipborad.
(WebCore::Pasteboard::writableDataObject): Get WCDataObject by Clipborad.

platform/win/ClipboardWin.cpp:

(WebCore::Clipboard::createDragImage): Change parameter name loc to dragLocation.
(WebCore::Clipboard::declareAndWriteDragImage): Implement declareAndWriteDragImage use WCDataObject exposed by Pasteboard.

platform/win/ClipboardWin.h: Removed.
platform/win/EditorWin.cpp:

(WebCore::Editor::newGeneralClipboard): Create Clipboard instead of ClipboardWin.

platform/win/PasteboardWin.cpp:

(WebCore::Pasteboard::createForCopyAndPaste): Create a Pasteboard.
(WebCore::Pasteboard::createPrivate): Ditto.
(WebCore::Pasteboard::createForDragAndDrop): Ditto.
(WebCore::Pasteboard::finishCreatingPasteboard): Create Pasteboard use Windows API.
(WebCore::Pasteboard::Pasteboard):
(WebCore::clipboardTypeFromMIMEType): Copied from ClipboardWin.cpp.
(WebCore::Pasteboard::clear): Ditto.
(WebCore::Pasteboard::hasData): Ditto.
(WebCore::addMimeTypesForFormat): Ditto.
(WebCore::Pasteboard::types): Ditto.
(WebCore::Pasteboard::readString): Ditto.
(WebCore::Pasteboard::readFilenames): Ditto.
(WebCore::writeURL): Ditto.
(WebCore::Pasteboard::writeString): Ditto.
(WebCore::Pasteboard::setDragImage): Ditto.
(WebCore::Pasteboard::writeRangeToDataObject): Write range to WCDataObject.
(WebCore::Pasteboard::writeSelection):
(WebCore::Pasteboard::writePlainTextToDataObject): Write PlainText to WCDataObject.
(WebCore::Pasteboard::writePlainText):
(WebCore::pathRemoveBadFSCharacters): Copied from ClipboardWin.cpp.
(WebCore::filesystemPathFromUrlOrTitle): Ditto.
(WebCore::writeFileToDataObject): Ditto.
(WebCore::Pasteboard::writeURLToDataObject): Write URL to WCDataObject.
(WebCore::Pasteboard::writeURL): Copied from ClipboardWin.cpp.
(WebCore::Pasteboard::writePasteboard): Copied from Pasteboard::writeClipboard.
(WebCore::Pasteboard::documentFragment): Copied from ClipboardWin.cpp.
(WebCore::Pasteboard::setExternalDataObject): Clipboard can set new IDataObject.
(WebCore::getCachedImage): Copied from ClipboardWin.cpp.
(WebCore::createGlobalImageFileDescriptor): Ditto.
(WebCore::createGlobalImageFileContent): Ditto.
(WebCore::createGlobalHDropContent): Ditto.
(WebCore::Pasteboard::writeImageToDataObject): Expose to make Clipboard implement declareAndWriteDragImage.
(WebCore::Pasteboard::writeURLToWritableDataObject): Ditto.

Source/WebKit/win:

WebCoreSupport/WebDragClient.cpp:

(WebDragClient::willPerformDragSourceAction): Get IDataObject from Pasteboard instead of Clipboard.
(WebDragClient::startDrag): Ditto.

12:50 PM Changeset in webkit [150771] by timothy_horton@apple.com

13 edits in trunk/Source

PDFPlugin: Main-frame PDFPlugin Accessibility
https://bugs.webkit.org/show_bug.cgi?id=116563
<rdar://problem/13458534>

Reviewed by Sam Weinig.

WebProcess/Plugins/PDF/PDFLayerControllerDetails.h:

Forward-declare a variety of accessibility methods.

WebProcess/Plugins/PDF/PDFPlugin.h:

Add convertFromPDFViewToScreen, boundsOnScreen, accessibilityObject, and
storage for our accessibility wrapper.

WebProcess/Plugins/PDF/PDFPlugin.mm:

Add WKPDFPluginAccessibilityObject.

(-[WKPDFPluginAccessibilityObject accessibilityIsIgnored]):
We want to be included in the accessibility tree.

(-[WKPDFPluginAccessibilityObject accessibilityAttributeValue:]):
(-[WKPDFPluginAccessibilityObject accessibilityAttributeValue:forParameter:]):
Grab values for accessibility attributes from the relevant sources
(mostly from PDFLayerController).

(-[WKPDFPluginAccessibilityObject readingModel]): Ditto.
(-[WKPDFPluginAccessibilityObject accessibilityAttributeNames]):
(-[WKPDFPluginAccessibilityObject accessibilityParameterizedAttributeNames]):
(-[WKPDFPluginAccessibilityObject accessibilityActionNames]):
Return the set of accessibility attributes, actions, and parameterized
attributes that we support.

(-[WKPDFPluginAccessibilityObject accessibilityIsAttributeSettable:]):
(-[WKPDFPluginAccessibilityObject accessibilitySetValue:forAttribute:]):
Forward some other accessibility methods to PDFLayerController.

(-[WKPDFPluginAccessibilityObject accessibilityFocusedUIElement]):
(-[WKPDFPluginAccessibilityObject accessibilityHitTest:]):
We have no children, so if a hit test makes it to us, it's ours.

(WebKit::PDFPlugin::PDFPlugin):
Make a WKPDFPluginAccessibilityObject and hook it up.
[FIXME: this could use some de-crapifying]

(WebKit::PDFPlugin::convertFromPluginToPDFView):
Transform a point from plugin space to PDFLayerController space.

(WebKit::PDFPlugin::convertFromPDFViewToRootView):
(WebKit::PDFPlugin::convertFromPDFViewToScreen): Added.
(WebKit::PDFPlugin::boundsOnScreen):
Return the PDFPlugin's frame in screen coordinates.

(WebKit::PDFPlugin::accessibilityObject):
Return our accessibility wrapper.

WebProcess/Plugins/PDF/SimplePDFPlugin.h:
WebProcess/Plugins/Plugin.h:

(WebKit::Plugin::accessibilityObject):

WebProcess/Plugins/PluginView.cpp:

(WebKit::PluginView::accessibilityObject):

WebProcess/Plugins/PluginView.h:

Add accessibilityObject(), to acquire accessibility wrappers from plugins.

WebProcess/WebPage/WebPage.h:

(WebPage): Add accessibilityObjectForMainFramePlugin();

WebProcess/WebPage/mac/WKAccessibilityWebPageObject.mm:

(-[WKAccessibilityWebPageObject accessibilityRootObjectWrapper]):
If the main frame has a PluginDocument that has an accessibilityObject,
use that one instead of the WebPage's.

WebProcess/WebPage/mac/WebPageMac.mm:

(WebKit::WebPage::accessibilityObjectForMainFramePlugin):
Return the accessibilityObject from the main-frame PluginDocument, if
there is one.

WebCore.exp.in: Export AffineTransform::mapRect.

12:27 PM Changeset in webkit [150770] by commit-queue@webkit.org

6 edits in trunk

[BlackBerry] Find-on-page should be able to convert the active match to selection when clearing all matches
https://bugs.webkit.org/show_bug.cgi?id=116837

Patch by Andy Chen <andchen@blackberry.com> on 2013-05-27
Reviewed by Rob Buis.

PR 291903
Internally reviewed by Mike Fenton.

Api/WebPage.cpp:

(BlackBerry::WebKit::WebPage::findNextString):

Api/WebPage.h:
WebKitSupport/InPageSearchManager.cpp:

(BlackBerry::WebKit::InPageSearchManager::findNextString):
(BlackBerry::WebKit::InPageSearchManager::clearTextMatches):

WebKitSupport/InPageSearchManager.h:

(InPageSearchManager):

11:39 AM Changeset in webkit [150769] by commit-queue@webkit.org

2 edits in trunk/Source/WebCore

Checkbox UX update.
https://bugs.webkit.org/show_bug.cgi?id=116838.

Patch by Tiancheng Jiang <tijiang@rim.com> on 2013-05-27
Reviewed by Rob Buis.

BlackBerry PR 342302.
Internally Reviewed by Jeff Rogers.
Remove old background and change pressed checkmark image.

platform/blackberry/RenderThemeBlackBerry.cpp:

(WebCore::RenderThemeBlackBerry::paintCheckbox):

11:25 AM Changeset in webkit [150768] by weinig@apple.com

2 edits in trunk/Source/WebCore

When the background is completely transparent we should be conservative and use the default scrollbar style, not the light one
https://bugs.webkit.org/show_bug.cgi?id=116836
<rdar://problem/13949905>

Reviewed by Simon Fraser.

page/FrameView.cpp:

(WebCore::FrameView::recalculateScrollbarOverlayStyle):
Don't use the light style when the background is completely transparent.

11:09 AM Changeset in webkit [150767] by Patrick Gansterer

10 edits in trunk

Use ICU_INCLUDE_DIRS in BlackBerry CMake files
https://bugs.webkit.org/show_bug.cgi?id=116210

Reviewed by Rob Buis.

Set and use the ICU_INCLUDE_DIRS variable to avoid
duplicated adding of the ICU include directory.

Source/cmake/OptionsBlackBerry.cmake:

Source/JavaScriptCore:

PlatformBlackBerry.cmake:

Source/WebCore:

PlatformBlackBerry.cmake:

Source/WebKit:

PlatformBlackBerry.cmake:

Source/WTF:

wtf/PlatformBlackBerry.cmake:

11:04 AM Changeset in webkit [150766] by efidler@rim.com

2 edits in trunk/Source/WebKit/blackberry

[BlackBerry] Fix subframe target added to new requests
https://bugs.webkit.org/show_bug.cgi?id=116602

Reviewed by Rob Buis.

In some cases we might be adding TargetIsMainFrame to a subframe
request causing an isMainFrame assert.

WebCoreSupport/FrameLoaderClientBlackBerry.cpp:

(WebCore::FrameLoaderClientBlackBerry::dispatchWillSendRequest):
Check we are actually loading the main frame before setting
ResourceRequest::TargetIsMainFrame target.

10:39 AM Changeset in webkit [150765] by fpizlo@apple.com

10 edits in branches/dfgFourthTier

fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793

Source/JavaScriptCore:

Reviewed by Mark Hahnenberg.

This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.

Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.

As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).

Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.

Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.

dfg/DFGAbstractState.cpp:

(JSC::DFG::AbstractState::executeEffects):

dfg/DFGFixupPhase.cpp:

(JSC::DFG::FixupPhase::fixupNode):

dfg/DFGSpeculativeJIT.cpp:

(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):

dfg/DFGSpeculativeJIT.h:

(SpeculativeJIT):

dfg/DFGSpeculativeJIT32_64.cpp:

(JSC::DFG::SpeculativeJIT::compile):

dfg/DFGSpeculativeJIT64.cpp:

(JSC::DFG::SpeculativeJIT::compile):

LayoutTests:

Reviewed by Mark Hahnenberg.

fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:

(myModBy2):
(myModBy1073741824):

9:52 AM Changeset in webkit [150764] by marcelo.lira@openbossa.org

3 edits in trunk/Source/WebKit2

[WK2][CoordinatedGraphics] Misuse of DrawingAreaProxy::setVisibleContentsRect() in WebView::updateViewportSize()
https://bugs.webkit.org/show_bug.cgi?id=116688

Reviewed by Noam Rosenthal.

Visible contents area passed to DrawingAreaProxy::setVisibleContentsRect()
must be calculated including the page scale factor and avoid crossing the
boundaries of the page contents size. In other words the DrawingArea
must know the actual dimensions of what it being drawn. If the
DrawingArea thinks the visible rectangle is bigger than it is, the
contents will be drawn pixelated and blurry.

UIProcess/CoordinatedGraphics/WebView.cpp:

(WebKit::WebView::didChangeContentsSize):
(WebKit::WebView::updateViewportSize):
(WebKit::WebView::visibleContentsSize):
(WebKit):

UIProcess/CoordinatedGraphics/WebView.h:

(WebKit::WebView::contentsSize):
(WebView):

9:10 AM Changeset in webkit [150763] by Carlos Garcia Campos

2 edits in trunk/Source/WebKit2

[GTK] WebKitWebView child widgets are not rendered with recent GTK+
https://bugs.webkit.org/show_bug.cgi?id=116794

Reviewed by Xan Lopez.

Since rev d22fd7223c75f4720ddb982c659efb0d8d7543c4 of GTK+ expose
events are not propagated to child GdkWindows anymore, and child
widgets are rendered via gtk_container_propagate_draw(). Since all
our children have its own GdkWindow (auth widget, inspector view
and windowed plugins) we don't propagate the draw signal making
them invisible with current GTK+.

UIProcess/API/gtk/WebKitWebViewBase.cpp:

(webkitWebViewBaseDraw): Chain up to the parent draw(), so it's
propagated to the children. This shouldn't have any effect in
previous versions of GTK+ because gtk_container_propagate_draw()
returned early when the child widget had its own GdkWindow.

9:01 AM Changeset in webkit [150762] by Antti Koivisto

12 edits in trunk/Source/WebCore

Tighten FontGlyphs::glyphDataAndPageForCharacter to take FontDescription
https://bugs.webkit.org/show_bug.cgi?id=116823

Reviewed by Andreas Kling.

FontGlyphs does not need to know about Font anymore.

platform/graphics/Font.cpp:

(WebCore::Font::Font):
(WebCore::Font::operator=):

platform/graphics/Font.h:

(WebCore::Font::isPlatformFont):
(WebCore::Font::glyphDataAndPageForCharacter):
(Font):

platform/graphics/FontCache.h:
platform/graphics/FontFallbackList.cpp:

(WebCore::FontGlyphs::FontGlyphs):
(WebCore::FontGlyphs::glyphDataAndPageForCharacter):

platform/graphics/FontFallbackList.h:

(WebCore):
(WebCore::FontGlyphs::createForPlatformFont):

Tweaked the name.

(WebCore::FontGlyphs::isForPlatformFont):

Move knowledge about platform font to FontGlyphs as it is needed for resolving system fallback on Mac.

platform/graphics/blackberry/FontCacheBlackBerry.cpp: