will have more time to respond whether it wants to
handle the touch events. (not have to return the
value from WebViewCore before the first tap is up)
Fix a potential null pointer exception.
we have to replace the AbsoluteLayout with
ViewGroup.Layout before setting it to the dialog
as dialog's FrameLayout doesn't accept AbsoluteLayout.
This should fix the crash when changing orientation.
EditorInfo:
Add a flag to tell the InputMethodService to never go into fullscreen
mode.
InputMethodService:
When the new flag is set, onEvaluateFullscreenMode always returns
false.
WebTextView:
Use the new flag, along with IME_FLAG_NO_EXTRACT_UI. Fixes
http://b/issue?id=2358360
Calendar.roll() breaks the year at the beginning of the year, so
use add() instead, which changes larger fields.
Also, only use 4 bins, since the last bin's boundary is not relevant.
Lastly, no need to return Calendar in beginningOfDay.
Fixes http://b/issue?id=2361382
Fix for http://b/issue?id=2219166
Requires a change to external/webkit
Remove the old change to update the WebTextView when a key is pressed,
since the IME does not generate key events. Instead, when the focus
changes, and the IME is serving the WebTextView, immediately clear
the cursor and update the WebTextView, so the user can continue
typing.
This logic was lost when we switched back using FLASH
instead of RAM for the cache.
Add back the CACHE_MAX_SIZE to limit the maximum
cacheable file.
Fix http://b/issue?id=2346132
problem adobe run into.
When a child view is created, we first hide it if
the webview is not ready to draw yet. This will avoid
the multiple resizing notification.
This takes care of the conditions where the bluez audio drivers
are not up and we try to make the call to connect the sink.
This would get rid of the hack in Settings app.
Use a NoTitleBar_Fullscreen dialog to implement the
full screen plugin. This runs in the same thread as
WebView (UI in the Browser case). One catch is that
the SurfaceView provided by the plugin needs to be
opaque if it doesn't want to see through the WebView.
The PluginFullScreenHolder translates the events to
the underline WebView. Special treatment in the touch
case as it needs to translate the coordinates.
WebView can't be panned, or double tap to zoom, or
long press to trigger the context menu while having
a full screen plugin.
Inside webkit, we also give the plugin element focus
when it goes to the full screen so that it takes key
events. While handling key events, we don't let it
loose focus or scroll out.
Todo:
When a plugin goes to full screen, we should make
sure the embedded plugin is fully visible. Otherwise
when we translate the touch events back, they will be
outside of the visible rect and will be ignored.
This is part 1 of 2-project check in.
Instead of processing each notification separately event (scheduling an alarm with AlarmManager for each event, posting notification to NotificationManager for each event, etc), only one alarm should be fired for each wake-up time. AlertService will look through the CalendarAlerts table and decides how to update the notication manager. This is more efficient and simplifies the codecode. It is also the long-term fix to elimiate overlapping notification ring tones e.g. DrooDrooDrooooid b/2194249
Also consolidated alarm scheduling code to one place.
Change-Id: If58ce278d55b28abad703f8aeee466d44952fcd0
Pass point to click in three steps.
1) See if point corresponds to cached node.
2) If so,send a message to webkit to see if the node is good.
3) Call webkit with point, and good/bad info.
This is a two-part change with external/webkit.
Fixes http://b/2249425
Fix for http://b/issue?id=2178786
Provide strings for input types file, submit, and reset, and allow
them to be passed down to native.
Requires a change in external/webkit.
Use this in various places where it should serve no purpose to deliver
both broadcasts. This is intended to reduce somewhat the flurry of
broadcasts that we churn through during boot.
This change fixes the context menu trigger behavior while
the user is selecting via touch. How if a user is selecting
text via dragging their finger, to trigger the context menu
they will have to lift their finger up, then issue a
longpress. This is consistent with the behavior of selecting
via the trackball.
