I made a Chrome extension which overrides 'New Tab' page. On the page, I created a clickable icon. I want to click and 'Task Manager' window to appear. Though I overridden the click-event handler (by simulating a keyboard event using KeyboardEvent() constructor) associated to that icon, nothing happens. This is the code:
event1=new KeyboardEvent('keypress',{
bubbles:true,
cancelable:true,
shiftKey:true,
code:'Escape',
key:'Escape'
});
window.dispatchEvent(event1);
return false; //Shift+Escape is Chrome shortcut for Task Manager
What am I doing wrong? I'd rather use Javascript.
The chrome task manager being such a low-level feature, I'd be surprised if you can invoke it by faking a keypress event even from the extension code. Key presses are filtered on the way down .. through the extensions and eventually to pages. This particular keypress is probably always intercepted at the highest level. It'd probably be undesirable to allow an extension or a page to know that the event occurred and it would certainly be undesirable to allow it to be intercepted. So I would think that Chrome isn't listening for the event to bubble back up before it invokes the window - it just does it and doesn't forward or listen for it bubbling.
Instead you'd need to ask Google for a special API call for the extension to call, proxied by the extension from any page code (if necessary). There doesn't seem to be an "chrome://tasks" even.
Related
I've been refactoring some javascript.
Previously, I had an HTML element open to Fullscreen when the user clicked on another element.
Now clicking the latter element initiates a server-side verification, instead.
Once the server-side verification check passes, the page reloads with extra data confirming the user is verified.
N.B. When the page reloads, it does so with a non-negligible amount of extra markup, styles, scripts and vectors. The reason I am re-factoring in the first place is to avoid the need to download all these extra assets (and keep them in the background, on standby) unless and until the user authenticates themselves
The first thing I discovered is that I cannot have the page reload and then have the HTML element immediately open to Fullscreen, because - and this seems entirely reasonable from a UX perspective, Firefox reports:
Request for fullscreen was denied because Element.requestFullscreen() was not called from inside a short running user-generated event handler.
Essentially, unless the user pro-actively interacts with the page, the Fullscreen API will not run.
(In this scenario, the user pro-actively interacted with the page before reload, which is not the same thing.)
So, I thought about it and then added:
document.body.addEventListener('mousemove', () => myElement.requestFullscreen(), {once: true});
Nope. The Fullscreen API still doesn't activate.
To check that I wasn't making an elementary error somewhere else, I tried:
document.body.addEventListener('click', () => myElement.requestFullscreen(), {once: true});
Which does work.
So: some user-interactions will successfully fire the Fullscreen API and others won't.
I have searched through the WHAT-WG HTML Spec but I cannot find a list of events which represent explicit and pro-active user-interactions on a webpage.
Does such a list exist?
Which other events apart from click will successfully activate the Fullscreen API?
Which JS events apart from click will successfully activate the Fullscreen API?
A small number of events will successfully activate the Fullscreen API.
Almost all of these events either imply a user-click or directly reference one:
change
click
contextmenu
dblclick
mouseup
pointerup
reset
submit
touchend
Further to the list of click-based events above, the Fullscreen API may also be activated via:
ScreenOrientation.onchange
Source:
https://www.aworkinprogress.dev/request-fullscreen
There has been a lot of discussions on Stack Overflow about how to dispatch a keyboard event programmatically with JavaScript. However, they are not simulating 'real' key presses in the sense that they merely fire a predefined event handler.
What I want is to simulate CTRL+F to bring up the browser search box. Is that possible at all?
window.find(…) does that.
In general, you're out of luck though trying to orchestrate native browser functionality from within a webpage. Browser extensions can do more.
Is there any Out Of the Box Vaadin 10 (and higher) event similar to window.onbeforeunload in JavaScript?
I've tried to use onDetach() or beforeLeave(), but it only works inside UI, and when user reloads the page or closes the page it's not working.
You can use the approach described in https://vaadin.com/forum/thread/17523194/unsaved-changes-detect-page-exit-or-reload that was already suggested in a comment.
At the same time, I'd urge you to be really careful with beforeunload events since they are in some situations fired even though the user is actually not navigating away from the page.
The most common case is if the user clicks a link that starts a download. In that case the browser will fire the event immediately when the user clicks the link. Slightly later when the browser receives the response headers, it will discover that it's a download and not a new HTML page to display. The end result is then that beforeunload has been fired but the previous page is still kept running.
If you want to use the event for cleanup, then the best approach today is probably a combination of the unload event and then using the new-ish Beacon API for notifying the server that the user has actually navigated away. Integrating this into a Vaadin application will require slightly more JavaScript, but it has the benefit that it will actually work.
Firefox exposes this service:
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIPromptService
Great! It is possible to make firefox display all kind of prompts, alerts, confirm boxes etc.
But can I register event listener anywhere? Basically I want to know when any alert, confirm, basic auth prompt, or even <select> options list appears on the screen. Is it possible?
As you already found out, there is a DOMWillOpenModalDialog event. This event might be sufficient for your needs, but you should keep some things in mind:
You need to actually add an event listener to all windows that you're interested in and that could open a modal dialog.
The event will be fired not only for nsIPromptService windows, but also for tab-modal (pseudo windows) and all other modal dialogs, such as Filepicker windows, sub-windows of the main preferences window, custom add-on provided windows.
There are other possible solutions, though:
Override nsIPromptService with your own implementation. You would then just keep a reference to the original implementation around that you got prior and pass the calls along after inspecting them or whatever.
You can overlay the actual modal prompt windows like any other XUL window, at least on Firefox Desktop, e.g. chrome://global/content/commonDialog.xul and/or chrome://global/content/selectDialog.xul to customize the window even more.
I found DOMWillOpenModalDialog event but I am not yet sure if it satisfies all criteria, especially <select> options:
https://developer.mozilla.org/en-US/docs/Web/Reference/Events/DOMWillOpenModalDialog
I am using a forever frame (COMET streaming technique) and in IE6 whenever a user clicks on a link (to even just basic JavaScript method) the connection is immediately dropped and has to be manually refreshed.
Has anyone come across a similar issue and / or know how to address it?
How to address it: return false from your event handlers (event.preventDefault for listeners etc) so that the link is not followed and so no navigation occurs on a simple left-click. Put all your logic in event handlers attached from script (and not javascript: URL, which are a horrible fragile hack that should never be used).
Further: if it's just a button that does some scripting when clicked, and doesn't actually point to anywhere usefully navigable, it shouldn't be marked up as a link. Ideally it should be a button (input or button with type="button"), which you can then use CSS to style like a link rather than a button if you prefer.
(Another approach, that requires less styling work but has accessibility drawbacks, is to do what SO does and just put an onclick event on a <span> or <div>.)