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.
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.
Make sure the application is always given the most recent configuration
when launcher. Use the current configuration, instead of whatever happens
to be set by the app, for reporting what it was launched with.
Change-Id: I2ffe306f56cc9092b640546dd0a28d2c29b9c0b3
(CrashData was a custom-marshalled crash-info class used for a server crash
reporting system I am deprecating). Use ApplicationErrorReport.CrashInfo
instead to report crash details (mostly the stack trace) from RuntimeInfo to
ActivityManagerService, since we're likely to need the crash information in
that form anyway.
Remove the (long-disabled) flags and support for the "Debug" button
in the crash dialog.
Further gut the ICheckinService interface by removing the crash-reporting
APIs (and everything that calls them), plus the synchronous checkin()
method (which has been stubbed out for a while now).
A new dropbox-based crash reporting system is in the works, but not part
of this change.
Merge commit 'ed2a70d6495b3f1928e36ad2b00ee4d33b2c0379' into eclair-mr2
* commit 'ed2a70d6495b3f1928e36ad2b00ee4d33b2c0379':
docs: add the Bluetooth developer guide,
Merge commit 'f6e32e72a902d9a309410bc5306a539ea850159f' into eclair-mr2
* commit 'f6e32e72a902d9a309410bc5306a539ea850159f':
Maintain a list of all Bluetooth docks.
This change allows the user to select-n-scroll. While a user
is in select mode, and they try to scroll, the textbox will
scroll in the direction of the selection, and expand the selection.
With this change, isBluetoothDock API can be used anytime and is not in tied
to dock state. The Dock State is a sticky intent so users
can query for the dock state.
Dr No: Eastham
Bug: 2133530
- removed the parcelling ability from Entity and EntityIterator and made them public
- added an EntityIterator abstract implementation that allow easy wrapping of a Cursor
- changed the VCard code to use the new APIs
Ideally, I would like to allow Activities in the same package to intercept mime
types but there is no way to get the current Activity information from a generic
Context object. For now, skip resolved Activities that are in the same package.
Bug: 2314904
