buffer is full. In that case, WebCore instructs the laoder to pause loading to give the plugin a chance to clear it's buffer and
continue.
Requires an external/webkit change.
Change-Id: Iec96a6325d92e979cbdc53289c2a20cad940ded2
Most content providers set up the data size in the cursor that
provides the file name, but sound recorder does not. Use the
stream size instead, which will work with all sources and
probably is no slower.
fixes http://b/2529352http://b/2524574
Change-Id: I32d101d07ca1d0fa2ff17c3c68393356902096d3
detached from Window long after it is destroyed.
As we freed the native side by setting mWebViewCore
to null, we can't access settings any more. In this
case, just hide both styles of zoom control.
Fix http://b/issue?id=2532401
1. start double tap
2. start pinch
3. start a popup window
4. about to detach from window
5. WebView size change which happens when IME is up
or rotation changed.
Partial fix http://b/issue?id=2530401. Dismiss the
zoom control of the main window when bringing up
the sub window
Two more cases of "View certificate" problems like b/2511635
One problem is that if there are multiple resources downloaded for a
page. In that case the mCertificate shown ends up being from the last
loaded resource instead of the main resource of the page. The solution
is to only set the certificate if the LoadListener is the
mIsMainResourceLoader as well as the mIsMainPageLoader.
A larger problem was the fact that the EventHandler.certificate
interface method (in this case the LoadListener.certificate
implementation) once per https connection instead of once per request
as was documented. That meant if an https connection was reused (which
happens frequently on login pages such as
https://www.google.com/accounts which use the POST -> redirect -> GET
idiom to avoid POST data page refresh warnings) then later pages never
were associated with an SslCertificate.
The solution was to change EventHandler.certificate to be called once
per request, specifcally before the request. This means we no longer
call the certificate method in the handleSslErrorRequest case, which
is okay because it includes the SslCertificate within the SslError and
that is what the BrowserActivity expects.
Change-Id: Icbd9bd98c89db82762d1d06de85e1cde2470300d
Comparing the hash code provided a consistent order but it was not a logical,
testable order as the hash code was not related to lexicographic ordering.
Remove a spurious '=' from a comment.
Bug: 2527671
Change-Id: Ia2248cb8acbc4d5759a624eec13da3837f7406b8
The existing view layout may not be an absolute layout,
and will throw a ClassCastException. Check to see if it
is compatible before the cast.
Change-Id: I7309600a1e7405a29e49a3bab469a164d51126ae
http://b/2526854
When HttpAuthHandler queries the WebViewClient to obtain a username and
password, we need to make sure that this is done synchronously when the request
is synchronous.
Bug: 2511043
Change-Id: I9ff2156cfb3c81edaf4a50ec7094a00a8f8ff91f
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
