I'm developing a (desktop) application in Electron (v1.6.2) that has a <webview> element (hosting 'guest' web pages) and a number of text fields, both <textarea> and <input type="text">.
We would like the user to be able to select text within the guest page inside the WebView and drag-and-drop it into the application's fields -- but, this isn't working.
Without doing anything special, I can select text in the guest page and drag-and-drop it into other applications outside of Electron.
E.g. -
Dropping it into a text editor, a text-field in a web-browser or my terminal window works fine.
It even works dropping it into a field in a different instance of my Electron application.
I can also drag text that is in the application, but not inside the WebView, and drop that in the fields Ok.
However, when dragging the text selected in the WebView, the fields in the application are not sensitive to events -- i.e. they receive no dragover or drop events, and focus does not switch to them as you would expect.
I've tried adding event handlers to the <webview> to intercept the mouse events (mosedown, mousemove, mouseup) in order to manually control things and tried to use event.preventDefault = true to disable the events from passing down to the guest page.
Everything behaves as I would expect util the moment when it is recognised that you are dragging text. Visually, this is the moment when the pointer switches to a closed fist and a ghostly rectangle appears showing the selected text. At that moment all mouse events cease to be received by the <webview> event handlers. It seems that the application is 'frozen' when text is being dragged.
Is there anything I can do about this?
It would work either to: -
- prevent the WebView from actually dragging text, and for me to simulate it programmatically;
- or to find a way to 'unfreeze' the application during the text-dragging, so that the fields are active, can see events and can receive dropped text.
This is a bug present in Electron v1.6.2.
It is fixed in Electron v1.6.5, released at the end of March 2017.
I've now updated to the latest stable release, v1.6.11, and the issue is fixed.
Related
So I'm working with an input type='time', and I don't understand why when the picker is opened, DOM events stop triggering.
My first assumption was shadow DOM, but it doesn't appear in the chrome devtool with the shadow tree setting enabled (I see correctly other shadow trees).
Furthermore, the picker even keeps focus outside the web page, for instance, if I wanted to close my broswer or click an icon on my OS's taskbar, the first click would make the picker close and only the second would do the action, although this behaviour occurs on Ubuntu 20.04 but not on Windows 10.
Here's a snippet that logs key presses, but whenever the picker is opened, events don't get triggered anymore.
window.addEventListener("keydown", () => console.log("key pressed !"));
<input type="time" id="input">
Is there a way to keep listening to events while the picker is opened ?
If there isn't, why so ?
Do the events get sent but the listeners can't catch them ?
Do the events not get sent at all ?
What is that interface made out of, is it even HTML ?
I interpret the question this way: when you refer to the "picker" UI, you mean the user interface elements which are not initially present within the bounding rectangle at first render. Here's an example from a similar question which shows a style used by Chromium browsers (around the time of Chrome version 83):
In the example above, I think you are referring to the "picker" UI as the lower rectangle containing the two vertical columns of two-digit numbers.
What is that interface made out of, is it even HTML ?
If you examine the shadow DOM in a Chromium browser, you can see that there is no HTML corresponding to the "picker" in this case. This is rendered like other native UI components provided by the browser, for example, the Window.prompt() dialog below:
window.addEventListener('keydown', ({key}) => console.log(`${key} was pressed`));
window.prompt('Try typing here first, then focus the demo window and type there afterward');
The code snippet above will result in a natively rendered prompt dialog UI like the one pictured in the screenshot below:
The user agent (browser) is fully responsible for the implementation, style, behavior, etc. for this UI: you cannot influence, control, modify, or respond to it like you can using DOM APIs.
Is there a way to keep listening to events while the picker is opened ?
No.
If there isn't, why so ?
Explained above.
Do the events get sent but the listeners can't catch them ?
No.
Do the events not get sent at all ?
There are no keydown events dispatched when the native browser UI is focused.
My iOS app uses a WKWebView with contenteditable = true on a specific div. I'd like to have code to make the keyboard show up for the web view, so the user can just start typing. Things I've tried that have had no effect:
Telling the web view to becomeFirstResponder (a long shot, because the web view wouldn't know what div to use).
Injecting JS to tell the div to focus(). (This works in other browsers, but sadly not in WKWebView)
Simulating touch events in JS via TouchEvent and dispatchEvent() in the hope of making it seem that the user had tapped on the div.
In the third case I also used addEventListener() to observe the simulated touches and compare them to real touch events from tapping the screen. It looks like the key difference is that the event's isTrusted value is false for the simulated touches.
I get that it's a potential security issue to let apps simulate touch events, but I didn't have any other ideas. I'm trying to get the keyboard to appear, what the user types is up to them and not something I want to mess with. Basically I want the same thing as calling becomeFirstResponder() on a UITextView.
This is very similar to a WebKit issue 142757 but I haven't figured out how to use the suggested workaround linked from there.
Clarification: I can set up and use an editable web view, but the keyboard doesn't appear until I tap on the web view. I'm trying to make the keyboard appear automatically, without requiring a tap to initiate editing.
I tried this in an iPad playground, and it works without any action on my part. It’s possible there is another view that is capturing touches, or “contenteditable” is misspelled, or something else?
I have been working on this specific requirement for more than 2 months now. But I haven't found a solution yet to disable the native keyboard when an input field is focused in a webview. I am building an app which has a built in keypad(essentially a view) and I want this to be displayed instead of the native keyboard.
What I've tried so far:
Add javascript eventListener for click events to display my keypad
using JavscriptInterface.(Works)
Set the webview focusable:false and
its parent's descendantFocusability to blocksDescendants (This works
but doesn't display the cursor on the input field)
Hiding the native
keyboard on resize event of javascript using loadUrl method.(Works
but the native keyboard is displayed momentarily before hiding the
keyboard)
Listening to the OnGlobalLayoutChange event to check if
the keyboard has been added. (Works but the result is same as
in the case above with a little improve in performance)
Force stop the IME service. (Works but the app has to be a system
app to force stop packages and the keyboard service has to be started
whenever the app goes to background.
Is there a way in which I can make this work?
You should set the windowSoftInputMode to stateAlwaysHidden for the Activity containing the web view. This should keep the onscreen keyboard hidden for the entirety of that Activity.
In an Android application, I use an WebView to load an html page with texts.
When long click on texts, the blue Chromium text selection handles show up so that I could drag to change the text selection and do actions like cut/copy/paste.
But the blue handles are on the Chromium level. Is it possible to control those blue handles on JavaScript level (or on Android level)?
For example, when some DOM events fired (or Android events), I want to move the right-side blue handles to the next line's 3rd character.
I've seen workaround to intercept the native Chromium selection and create customized selection handles, e.g. https://github.com/btate/BTAndroidWebViewSelection, but here I'm wondering if I could directly get control over the Chromium's text selection handles via some Chromium's public API either open to JavaScript or Android?
I have a simple input (type="text") html control being displayed inside a WebView in our iOS application.
When the text is selected inside the input control, an iOS dialog automatically appears with four options: "Cut", "Copy", "Replace...", and "Define". I need to be able to remove or disable, at minimum, the "Define" option.
The reason for this is because our application is typically used for connecting to another device on a local area network lacking an internet connection. When the "Define" option is pressed, it would appear iOS attempts to make some sort of internet request to search for something. When there is no internet connection present, the iOS application appears to lock up for a full 5-10 seconds, wrecking all sorts of havoc in our application.
Is there any sort of CSS, HTML META, or iOS option to prevent the "Define" option from being available?
In case anyone is confused, here is an example of what I'm talking about:
By using css you can prevent selection of the text, so menu will not apper( with user-select:none).
Also you can disable this menu to show using this link prevent define from showing in edit menu