After about 4 taps, this starts to return that the tap was
in the plugin. Before that, the plugin doesn't have focus.
Derek may want to verify that everything is working as it
should -- maybe it just takes that long for webkit to take
focus.
companion fix in external/webkit
Change-Id: I80ffba6c55876b0af9c305c539a10e8e8ed7cb3c
http://b/2521087
Fix for http://b/issue?id=2519667
Do not return so that we can fall through and pass the shift up
to the page.
Change-Id: Ib3c07f2d39e772f88dd6eee6390034e5a3e3e026
WebView's mCertificate member was not cleared when going to new
pages. Rather than clearing mCertificate as was done in previously in
WebView.goBackOrForward, we now clear when CallbackProxy receives a
PAGE_STARTED message.
This problem was highlighted whenever we went to a https page that was
in the cache, since the cache does not store certificate information,
so "More > Page Info > View Certifcate" was showing the certificate of
the last non-cached page because it had not been cleared. See also
b/2516638 "SslCertificate information not cached by CacheManager"
Change-Id: I40284f22ceb7150a6b20ecc2741f6153ed9a3276
the new zoom center. This should avoid the rounding
difference which caused the video in nytimes.com
not fully fit in the current view.
Fix http://b/issue?id=2512510
Create a concept of blocking messages on destruction similar to that in
WebViewCore.java. This is to prevent what I think is a race condition
caused by an orientation event occuring just before the frame is destroyed,
resulting in the orientation listener being called back just before it
is disabled, but posting its message after the messages have been removed.
This results in the orientation event being delivered to a NULL native frame.
This is a fix for issue 2485033. It is not a final fix, but just starting with this so it can be discussed on code review. The line in question
was added to fix issue 1690652.
Updated fix. Stores the url before it is cut during a redirect. Forwards this to the reponse instead of the cut url.
Update 2: Using the old originalUrl
Change-Id: I286084451aa45e51d5d07811f9d119cf83849592
When a page is loaded, Flash won't be the touch target.
This is ensured by another CL in external/webkit. When
user taps or uses nav key to make the Flash to be the
document focused node, it will take all the touch
events without time out. If Flash didn't call prevent
default, these touch events will be reprocessed by
the Browser. For double tap and long press, Browser
needs to detect and generate them for Flash.
While Flash is in full screen mode, it will take all
the touch events. If Flash doesn't consume them, they
won't be reprocessed by the Browser. Browser does need
to detect and generate the special events like double
tap and long press for full screen Flash.
Here are changes made for JavaScript touch events.
1. preventDefault on touchMove works now. If the author
calls preventDefault on touchStart, UI will not handle
this touch sequence. If the author didn't call preventDefault
on touchStart, it can call preventDefault on the first
touchMove to prevent UI from panning the page. We
currently do not support alternating preventDefault
during touchMove.
2. The first touchMove is only sent when the movement
is more than the system slop. There was a bug introduced by
https://android-git.corp.google.com/g/#change,42848
where the touch events are not sent to WebCore if
preventDefault is called. This is fixed now.
3. Move sending TOUCH_EVENT to WebCore into each state.
So if user stops a fling and continue drag, it won't
send the touch_down as we are in drag mode.
4. Remove event time as Adobe doesn't need it any more
Fix http://b/issue?id=2438503
Fix http://b/issue?id=2478701
Fix http://b/issue?id=2390587
Call native LayerAndroid::subtractLayers so
the layers can be removed from the visible portion of the screen
when computing how much to scroll.
companion fix in external/webkit
Change-Id: Ib441b826ab5b2baaba20f41f392848a28a9e09ee
http://b/2453841
Update the cookie parser to correctly detect "a=b" cookies and add comments.
Also change the comparator to compare null values before the name so that all
cookies with null values come after cookies with values.
Also added a cts test in cts project.
Bug: 2487245
over scroll vertically. In horizontal direction, if
the page can't be zoomed and the current content just
fit, we will not do over scroll.
Per UI request, only draw the shadow when title bar
is not visible.
This fixes the layout test failure in fast/xmlhttprequest/xmlhttprequest-html-response-encoding.html
Bug: 2218794
Change-Id: If86c5dbb72b21400bd0fb6981de1a6fdf9b40fe7
completed before we've successfully syncd the webview dimensions from Java to
native and in this case, we end up syncing a height of 0 to WebKit. This causes
hit detection to fail, as WebKit thinks we have a 0-height visible area. This
patch fixes this scenario by syncing the height of the webview back to WebKit
in the case that the first layout comes back before we've sent our dimensions.
Fix for b/2449863
Change-Id: Id72c37b17411f3409edc7104d83ca5ffd17ab09b
commit 35ade1c72b5fe34c177712108ccbc070eab11a87
Author: Shimeng (Simon) Wang <swang@google.com>
Date: Thu Mar 4 16:29:01 2010 -0800
Alternative way to fix the history picture drawing issue.
Disable zoom part for history picture mode.
Bug: 2462039
commit 1a27acaa36c60546e5e6b2e1caf4ce5488dad14b
Author: Shimeng (Simon) Wang <swang@google.com>
Date: Thu Mar 4 16:06:41 2010 -0800
Use the screen width to derive the desired scale.
This is to fix the history picture draw issue. Since the mActualScale
will be changed in some other places.
Bug: 2462039
Separate out state when find is up and is empty.
Request a scroll when setting a match, rather than when drawing.
Don't draw if there's no match.
Companion fix in external/webkit and packages/apps/Browser
http://b/2370069
