I am tring to create a Chrome extension that adds a contex menu entry when ever the right
mouse button is clicked.
I also need for the new entry to be displayed when the right click is on a flash object (Such as Youtube clip) I cannot find a way to do it...
Can it be done? What directions should I check?
Can't do this (not from JavaScript, and probably not from Flash, either). The menu that you get when you right-click in a Flash object is generated by your Flash interpreter, not the browser - and IIRC can't be overridden.
Related
I am creating a electron application that looks similar to google chrome with multiple dynamic tabs for different pages. The application also supports multiple open windows. I want to be able to drag tabs between these windows. I already know how to send messages between my windows with the ipcRenderer but I am coming up against a few roadblocks:
1) I cannot drag an html element outside of a window. How can I drag the tab (or something that looks identical) outside of the window?
I've found a discussion on the atom forums where someone claimed they were able to achieve this, but do not elaborate on how. They claim "Native HTML5 Drag and Drop in combination with IPC messaging was the solution". Someone else links a GitHub example below, but the example has since been removed.
2) How do I detect when a tab is dragged onto another open window (Mouse released on other window)?
Again the discussion suggests I use IPC messaging to do this, but I have not found a way to get the id of the window you release the mouse on.
Edit:
I have found a solution to issue 1. The mentioned discussion was right and using default HTML5 dragging behavior was able to create the effect I wanted. Issue 2 still stumps me. I understand the concept of alerting all other open windows with an IPC message to prepare for an incoming drag but I am still unsure how to get the id of the window and the position you dragged to on it so you can send the tab information to the correct place.
I know this is a bit old. but instead of dragging a tab to a new window, what about a context menu on the tab with a [Send to window].
using React for example (not that you'd have to), you could JSON.stringify the data you've used to render the tab, send it to the child window, JSON.parse it and render it in a new tab on the child window.
Not quite the effect of dragging but the same end result.
For communication between windows:
https://medium.com/#kahlil/how-to-communicate-between-two-electron-windows-166fdbcdc469
The gist: What's the best way to escape a Flash object's focus on a webpage?
Context:
I have a hotkey listener (an AutoHotKey script) running in my tray. If the script detects the command Alt+Shift+F6 while I am clicked into a Flash object on a webpage, it activates and sends key combinations to Flash to pull certain data logs. After this process completes, I want to call up a JavaScript file on that same browser tab that requests additional information from the user - basically, a tiny UI with additional text fields available in a third-party bug tracker. To do this, I want to send a javascript: command to the address bar using Ctrl+L and having AutoHotKey paste in the full call to the JS file.
A visualization of a possible environment:
The problem:
I need the user to be clicked INTO Flash in order to pull the data logs. However, I need the user to be clicked OUT of Flash for Ctrl+L to actually work - Flash appears to eat all keystrokes at the browser-level when one of its objects has focus.
A possible solution: The easiest way to go about this would be to simulate clicking on the stage, which borders my Flash object on every side. This should work, but I must assume the stupidest possible user. Such a user would somehow limit their current browser window to only be as big as the Flash object (if not smaller), click into it, and attempt to use the hotkey. In this case...I have no idea where I should click, because it could be outside the browser. Further, I don't believe I can assume that all browser address bars are similar amounts of pixels south from the top of the window.
Additional complicating factors:
I want this to work for the user's default browser. (IE, Chrome, Firefox, Safari are my big targets.)
AHK does not provide any native DOM or COM hooks to anything except IE.
Ctrl+Tab and Alt+Tab shenanigans do not appear to work. That can get me to other tabs/windows, but returning to the tab/window with the Flash object still causes Flash to 'eat' further keyboard input.
While I'd be open to using another scripting language than AHK if it could overcome this Flash focus hurdle, I do not know how to create a keylistener that sits in the users tray until activated by a hotkey.
I have no access to the Flash object's code, and it contains no logic to interpret a key combination as a way to break focus or launch a script.
Would it be possible to use WinMaximize to maximize the size of the window? If you do that it should be easier to set up the script to avoid clicking outside the browser.
Perhaps look at ControlFocus and/or ControlSend (using the "edit1" control in IE and FF -- unfortunately, Chrome doesn't expose the "address bar" as a "control" this way but if you test for Chrome first, you can implement your "click outside the Flash box" method for that case).
I'm working on an app, which is based on Firefox and what I need to build is an in-app password manager. I'm planning to populate it once and hide it from view outside of the window frame, bringing it in-frame when it is needed. Now, I have read about the rules applied to moveTo, namely
"You can't move a window or tab that wasn’t created by window.open.
You can't move a window or tab when it’s in a window with more than one tab."
I was wondering if there are any exceptions to that rule? I have full access to chrome, so I was wondering if there's some more low-level way to achieve the moveTo form there?
Thanks a lot!
The restrictions of window.moveTo() don't apply to code running with system privileges. I just tried typing top.moveTo(-1000, 0) into the Error Console - it moved the window off-screen, something that unprivileged code isn't allowed to do. Still, opening the window off-screen is not possible as far as I know (you can however move it in a load event handler, when the window is still invisible). Also, the task manager still shows that window - it is possible to Alt-Tab to it, then press Alt-Space and choose "Move" from that system menu (that's on Windows).
I am looking for a way to improve the workflow in a PHP based CMS. There is a lot of switching between the editor mode and the preview mode of the page. The editor mode is huge to load, and so I would like to open the preview mode in a different window.
I don't want to use new windows or an iframe within the current window to keep the workflow simple and to avoid confusion.
Is there a way to explicitly open a new tab (not window), and to jump to that tab from a document, in Firefox? The number of users is limited, so there is the possibility to set up the client with the necessary extensions / permissions.
I know Firefox can be forced to open all links in tabs, but I think that won't cut it, as I still can't address and focus the newly opened window.
Thanks for all the great answers everyone. I have now enough material to decide whether I'll take the greasemonkey approach, rely on the user to set up "open in tabs" and address the window by name, or use a "inline" HTML solution as so many of you suggested. I am accepting the answer that I feel went most effort into.
There is no way to force a window to open as a tab. It's all dependent on the user's preference settings.
I second the answers that say you should do this in HTML using Javascript. Then it can work in all browsers that support JS.
I would put two divs on the page and show/hide each div depending on which tab is selected. If you are clever about this you could trap the click on the tab and determine if the user left-clicked or middle-clicked. If they left click you load that tab on the page. If they middle-click you let the browser open a new tab/window (according to the user's prefs, don't try to force it), and leave the current window unchanged (that is, don't switch to the new tab). The action for clicking on the tab would be to use AJAX to load the contents of the remote document and put it into the tab. Use Javascript to modify the URL before submitting the AJAX request so that the server knows to send a web page fragment instead of the whole page.
The advantage of this dual-natured solution is that the tabbed approach will work the way you want it to work for the majority of cases, but for users with, say, two screens, or who prefer switching between browser tabs, they will still have the flexibility to work in multi-window mode. This can all be done without any browser extensions and it should work equally well in IE as well as Firefox, Opera, etc. Avoid locking yourself into one browser, even one as excellent as Firefox. One day a customer will need to use Opera or Safari and you'll be stuck.
You say you don't want to use an iframe to avoid confusion. Now I don't know about the layout of your website, but I've been using the approach that the editor opens in its own div right next to the content being edited and the content is being live updated as you edit. No need to change tabs.
(If the window is too narrow there are HTML tabs Edit and Preview)
It does not seem to add confusion to the user and for me this approach works really well. Maybe it's worth considering in your case.
What about using iframes and JavaScript?
I know you said you want to avoid 'confusion using iframes', but in my opinion if you really need to load different pages at the same time this is the best option.
In theory, you could create your own tab system using javascript or even better, using jQuery, because its UI module offers pretty cool tab control.
For every tab you could load separate "headerless-footerless" version of your specific admin page inside <iframe> element. If user wanted to modify something different, he will simply click on the tab and bring different iframe.
All this could also be done using AJAX, but iframe solution is quite easy as you just need to load ready page and all postbacks are already handled by original page and separated from master-admin-page.
You might also need to play a little bit to set correct height of your iframe to fit all the content without scrollbars, but this again, is just bit of javascript.
Nope, there's no way to force the opening of a new tab, simply because this would be unsupported by un-tabbed browsing
You can only set it to open a new window, not a new tab.
Greasemonkey springs to mind - a quick google gives open in tabs on left click. I think you could modify that so it only runs on one particular page, and you'd be up up and away.
This question made me wonder if HTML 5 allows that sort of specification, and it doesn't (nothing in one of the other hyperlink attributes, either). A new browsing context is a new browsing context, there's no way to express a preference for tab over window or foreground over background.
You can't force a tab, but if you use a target with a specific name, like target="my_cms_window", many browsers will open this as a new tab. Additionally, they will remember the name and if you use the target repeatedly, put the contents in the same tab. I have found that this works pretty well in the real world.
I'm using a custom right click context menu for a flash app (overriding the default adobe menu). For this Uza's right click solution ( http://www.uza.lt/blog/2007/08/solved-right-click-in-as3 ) works well.
However, flash player plugin (for Firefox/Chrome etc) has a bug which breaks usage of international characters when its using WMode for the html embed. WMode="widnow" works.
http://bugs.adobe.com/jira/browse/FP-501
The issue can be seen better here -
http://www.5etdemi.com/blog/archives/2005/06/firefox-wmodetransparent-is-completely-screwy-and-breaks-textfields/
The problem
I need to capture the right click event fired from Flash player plugin to the web browser container without using WMode on the html embed tag (ie. WMode="window")
Does anyone have an idea about this?
The right-click JS hack works in opaque and transparent mode because the browser is rendering the Flash inside its own display tree. In this mode, the browser receives mouse events, allows them to be handled by JS, then passes them to the Flash plugin. (This is the reason why there are bugs with entering accented or non-latin characters in transparent mode, because some browsers don't pass them through properly).
In the other window modes the Flash object is not part of the html DOM in the same way. Instead it is just given a rectangle of the display and can draw to it directly. It also gets its keyboard and mouse events from the OS directly, so I wouldn't expect any JS context menu hacks to work in any mainstream browser.