| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
* changes:
don't pre-round rects, since we will zoom (arbitrarily) after we record the geometry.
|
| |
| |
| |
| |
| |
| |
| | |
geometry.
This fixes the funny case of <canvas> elements being scaled twice: once by our scaleFactor() and
then again by this roundToDevicePixels method.
|
|/
|
|
|
|
| |
not merge.
This has already been submitted to master branch.
|
|
|
|
| |
This has already been submitted to master branch.
|
|
|
|
|
|
|
|
| |
webkit.org. Do not merge.
See https://bugs.webkit.org/show_bug.cgi?id=29099
This has already been submitted to master branch.
|
|
|
|
|
|
|
|
| |
not merge.
The patch in https://bugs.webkit.org/show_bug.cgi?id=29133 landed.
This has already been submitted to master branch.
|
|
|
|
|
|
|
|
|
| |
This was made in change 95e3d862bbab761f8caaf1d1b54065f67b9a5148.
See https://android-git.corp.google.com/w/?p=platform/external/webkit.git;a=commitdiff;h=95e3d862bbab761f8caaf1d1b54065f67b9a5148#patch1
This will help avoid noise in the diffs when upstreaming Android-specific changes to webkit.org.
This has already been submitted to master branch.
|
|
|
|
|
|
|
|
| |
webkit.org. Do not merge.
This will avoid noise in the diffs when upstreaming Android-specific changes to webkit.org.
This has already been submitted to master branch.
|
| |
|
|
|
|
| |
the V8 build.
|
|
|
|
|
|
|
|
|
| |
merge.
These were removed from webkit.org in http://trac.webkit.org/changeset/44944.
This should have been picked up in https://android-git.corp.google.com/w/?p=platform/external/webkit.git;a=commitdiff;h=d227fc870c7a697500a3c900c31baf05fb9a8524, which syncs to webkit.org R47420.
This has already been submitted to master branch.
|
|
|
|
| |
Fix http://b/issue?id=2159794
|
| |
|
|
|
|
|
|
|
|
| |
Webkit implementation for passing in the data for file uploads.
Requires a change to frameworks/base to not break things; also
requires a change to packages/apps/Browser to work.
Fixes http://b/issue?id=675743
|
|\
| |
| |
| |
| | |
* changes:
Fix bug 2132969
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Check for a user gesture before adding the history item during a fragment
scroll. The bug has been reported to webkit.org with the suggested fix. Although
upstream webkit does not have the user gesture additions defined by
ANDROID_USER_GESTURE.
Bug: 2132969
|
|/
|
|
| |
to "Apple Computer, Inc."
|
|\
| |
| |
| |
| |
| |
| | |
Merge commit 'a7280594a8eac3503fe491d2ea02ce684fdf8744' into eclair-mr2
* commit 'a7280594a8eac3503fe491d2ea02ce684fdf8744':
Fixes build bustage due to missing include in Geolocation.
|
| |
| |
| |
| | |
Change-Id: Iea9209faba25a9b4ea4e351218c8c1eecf36d07f
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| | |
stopped when the page is unloaded.
Merge commit '0c7394a4459ba850766d303b4307add7189cf5f3' into eclair-mr2
* commit '0c7394a4459ba850766d303b4307add7189cf5f3':
Fixes a WebKit bug where ongoing Geolocation requests are not stopped when the page is unloaded.
|
| |
| |
| |
| |
| |
| |
| |
| | |
the page is unloaded.
This fixes bug http://b/issue?id=2164673
Change-Id: I68a615c0b82bcee2a4a61dc0433a4f9321780ad1
|
| |
| |
| |
| | |
Database.changVersion().
|
| |
| |
| |
| | |
color.
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| | |
text, so that the real background"
Merge commit '2097884b9e1630c3855a8580f84a308163e085e7' into eclair-mr2
* commit '2097884b9e1630c3855a8580f84a308163e085e7':
Revert "Don't extend the arrow asset of the combo box over the text, so that the real background"
|
| |
| |
| |
| |
| |
| | |
the real background"
This reverts commit 02b5ebb30fc88967b843818cbc61987f9dc9685d.
|
| |
| |
| |
| | |
http://b/issue?id=1817561
|
|/
|
|
| |
http://b/issue?id=2146657
|
|\
| |
| |
| |
| | |
* changes:
Don't extend the arrow asset of the combo box over the text, so that the real background color is used. Re-instate using the correct color for the text.
|
| |
| |
| |
| |
| |
| |
| | |
real background
color is used.
Re-instate using the correct color for the text.
|
|\ \
| | |
| | |
| | |
| | | |
* changes:
Update <video> implementation after new IRC discussion with Eric Carlsson.
|
| |/
| |
| |
| |
| |
| |
| |
| | |
- move poster drawing on the WebKit side
- get rid of the child views
- add prepareToPlay method to the MediaPlayer iface.
Fixes http://b/issue?id=2156592
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The problem is that if updateWidgetPosition calls layout, the FrameView will
layout with 0x0 dimensions. Then, we resize the view and try to relayout. This
causes the body to be marked as needing a layout. But, the body does not get a
chance to relayout. If updateWidgetPosition does not layout, the view size will
match and the body will not be marked for layout. This makes everything sane
after layout of the iframe.
The root of the problem is that we are calling FrameView::layout() while in the
midst of a layout. This is causing a child RenderObject to need a layout
without the parent object needing a layout. We avoid this by not laying out
until we set the FrameView dimensions.
Bug: 2048855, 2134215
|
|\ \
| | |
| | |
| | |
| | | |
* changes:
always update the WebTextView from the input element
|
| |/
| |
| |
| |
| |
| |
| | |
Even if the input element doesn't have focus, synchronize
the WebTextView if the pointers match.
fixes http://b/issue?id=2096746
|
|/
|
|
| |
Bug: 2151004
|
|
|
|
|
| |
Files that include FontPlatformData.h apparently depend on StringImpl.h already
being included.
|
|
|
|
|
| |
KURL::protocolIs no longer likes "javascript" and has a different method called
protocolIsJavaScript.
|
|\
| |
| |
| |
| | |
* changes:
When detach the top Document, clean up the touch listeners and reset needTouchEvents.
|
| |
| |
| |
| |
| |
| | |
needTouchEvents.
Fix http://b/issue?id=2145333
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we record/draw the DOM N times (for speed), webkit sees what we're doing in certain places,
and sends us different rectangle coordinates. These were all being antialiased (by default).
However, when we are also zoomed, the rects now fall on fractional coordinates, and with aa,
we will double-draw the edges where those rects should have seamed.
The fix is to disable antialiasing for a class of rects that we record from webkit. We are probably
disabling for more cases than is necessary for the current bug, but knowing which ones are
"required" is tricky, and there (as yet) seems to be no down-side, since we never draw the page
rotated at a funny angle (where the rect edge would look jaggie).
http://b/issue?id=2132971&cookieId=2009268114917835
http://b/issue?id=2127763&cookieId=2009268114931860
|
|
|
|
|
|
|
| |
Since we are never rotated, and when we are zoomed, the
antialiasing can double-draw the shared border for images that are meant to seam (ala nine-patch)
http://b/issue?id=2105990&cookieId=2009268085657820
|
|
|
|
|
|
|
| |
We only care about the user gesture during a location change. Add the
m_userGesture field to our ResourceRequest and check the value in
canHandleRequest. This could be cleaner if WebCore passed around the
ResourceRequest rather than constructing a new one.
|
|
|
|
|
|
| |
to be the focus of the document so that it can receive key
events. This has the same logic as in PluginViewMac.cpp's
handleMouseEvent().
|
|
|
|
| |
Send up a boolean to indicate if the touch icon url is precomposed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the "viewport" meta tag, you can specify "target-densityDpi".
If it is not specified, it uses the default, 160dpi as of today.
Then the 1.0 scale factor specified in the viewport tag means 100%
on G1 and 150% on Sholes. If you set "target-densityDpi" to
"device-dpi", then the 1.0 scale factor means 100% on both G1 and Sholes.
Implemented Safari's window.devicePixelRatio and css media query
device-pixel-ratio.
So if you use "device-dpi" and modify the css for font-size and image
src depending on window.devicePixelRatio, you can get a better page on
Sholes/Passion.
Here is a list of options for "target-densityDpi".
device-dpi: Use the device's native dpi as target dpi.
low-dpi: 120dpi
medium-dpi: 160dpi, which is also the default as of today
high-dpi: 240dpi
<number>: We take any number between 70 and 400 as a valid target dpi.
Fix http://b/issue?id=2071943
|
|
|
|
|
|
| |
calls
Change-Id: I7881e711af7ec905e5c120e8e2fd4b0b7ba5e840
|
|\
| |
| |
| |
| | |
* changes:
bump up the RLE cutoff, since RLE is *only* supported in drawBitmapRect(), and therefore we should only trigger it when there is no other way to support the image. Now that we have ashmem (yay!!!) memory pressure is not so bad. This happens to also fix google reader site, which sends down large (but not giant) index images but doesn't trigger our drawBitmapRect() code.
|
| |
| |
| |
| |
| |
| |
| |
| | |
and therefore we should only
trigger it when there is no other way to support the image. Now that we have ashmem (yay!!!) memory
pressure is not so bad. This happens to also fix google reader site, which sends down large (but not
giant) index images but doesn't trigger our drawBitmapRect() code.
|
|/
|
|
| |
WebCore::MediaPlayerPrivate
|
| |
|