What is the proper way to us the "alwaysOnTop" property for components or windows?
If I define a window - say a toolbar - and set alwaysOnTop: true, shouldn't that keep other windows from obscuring it?
Do windows with this property need to be registered with Ext.WindowManager?
Long story, I'm using the Desktop code (see here: https://examples.sencha.com/extjs/6....top/index.html). You will notice that you can move the windows over the bottom toolbar - this should not really happen.
Adding alwaysOnTop: true to that taskbar code alone has no effect but doing subsequently doing this does:
Ext.WindowManager.register(taskbar)
Problem is that win.toFront() no longer seems to work for other windows on the desktop. Such that if window A overlaps window B, B.toFront() will have no effect.
So, the question is, what is the proper way to use alwaysOnTop for specific items yet have other windows behave as expected?
Have you checked below link? I think we have to apply other methods like this for achieving the output.
Always on top
Ok, so you still need to register the windows you want 'alwaysOnTop'
but it turns out the reason why the window will not come to the front is that the ZIndexManager will not promote a window up if there is any window that has been register as "alwaysOnTop".
The function bringToTop() contains the following code:
if (!comp || zIndexStack.find('alwaysOnTop', true)){
return false;
}
This will keep the window in question from moving up in the stack.
removing the alwaysOnTop comparison seems to solved my issue. When setActiveCounter is executed on your component, that will trigger a call to resort the collection and place windows on that have 'alwaysOnTop" set on the top of the stack, followed by the one in question.
The result of this is that the task bar at the bottom of the desktop will always stay on top, and your floating windows promotion/demotion will behave as they should.
Related
Help to make the same window, as with Skype when we call, we see window with call info, via Electron. The point is that this window is always on top of all Windows on your computer, including games.
The alwaysOnTop parameter: true sets the window in front of all other Windows, but the game covers it in full-screen mode.
Is it possible and how it can be implemented in the Electron or in what ways it can be done?
On macOS, it is possible to set the window to be always on top with more options by using the BrowserWindow instance method win.setAlwaysOnTop() instead of the alwaysOnTop flag:
win.setAlwaysOnTop(flag[, level][, relativeLevel])
Values include normal, floating, torn-off-menu,
modal-panel, main-menu, status, pop-up-menu, screen-saver,
and dock (Deprecated). The default is floating.
You may want to try all possible level values to get the one which may fit your needs.
Setting window.setAlwaysOnTop(true, "normal") does the trick as suggested by
Alok Kamboj
I was stuck on same thing and managed to make always on top work using this particular hack(in this particular order) -
// Tricky way to bring cam bubble to top over fullscreen windows on mac
win.setVisibleOnAllWorkspaces(true, { visibleOnFullScreen: true });
win.setAlwaysOnTop(true, "floating");
win.setFullScreenable(false);
// Below statement completes the flow
win.moveTop();
Now this used to work when I was on electron 9.3.5 and stopped working after I upgraded to 13.1.2. Now I'm able to achieve the same thing using "normal".
I'm writing about the age-old problem of trying to keep the start menu from appearing.
I've read everything I've been able to find on the web, including 2 previous stackexchange threads on closely related topics:
How to disable Windows keys (logo key and menu key) using Javascript
and
Is it possible to block the Windows Key from a web browser?
Now, as people have discussed on those threads, it is not possible to actually block the windows key. I understand that this must be done like that for security, as it would be very dangerous if a script running inside a browser could hijack keys from the operating system. Pretty much for the same reason that a website can never be allowed to go full screen automatically without the user having at least clicked on something.
That's fine.
I'm wondering, however, if instead of trying so desperately to block the windows key, we could instead keep the start menu from appearing. I know it might sound bonkers, but what made me think about it was the solution for dealing with the "context menu" key. Instead of blocking the key, you can just add oncontextmenu="return false;" to the body tag, and then you don't even need to worry about the key.
I understand that the difference between the context menu key and the windows key, is that the context menu appears on the browser, whereas the start menu lies outside the scope of the browser, in the UI of the operating system. But I thought I would ask the question anyway.
For clarity, I'm looking for any solution whatsoever that will allow me to keep the start menu from appearing while my js script is running in the browser, whether it's by blocking the windows key or preventing the start menu from appearing.
Thanks in advance!
I'm developing a web based game using processing.js, my question relates to pure javascript code to manage browser windows.
The game is a maze of small browser windows (200px*200px) each border can be a wall or a passage to another window. My issue is that if I close the window I'm coming from then I try to get back it doesn't re-open, even if I use the same function that was used before.
I've got a git repo running here : GitHub - TheMidst.
If you want to reproduce the "error" :
Pull the code from github:
launch index.html (in your favorite browser, I use chrome).
Don't wait up and click the start button -> level0.html opens.
Go on the right by clicking on the right hand side of the canvas->
level1.html opens.
Go back on your steps -> level0.html still opens.
Go back on the right towards level1.html and it will not be re spawn
... => this is my issue.
/js -> contains a windowScripts.js that handles opening and closing of windows through functions, this is the heart of my window manager and it's buggy.
/levels -> contains each level as a html page.
/pd -> contains the sound of the game as Pure-Data patches (yeah !)
The game is far from finished yet, so everything is far from perfect. Any help would be greatly appreciated.
Cheers.
edited to add some code
to open a popup i use : popUp(1); //1 being the number of the level i want to open.
this relates to this js function
function popUp(winNum) {
var windowFeatures = "toolbar=0,location=0,directories=0,status=0,menubar=0,scrollbars=0,resizable=0,left="+(winVars[winNum][0])+",top="+(winVars[winNum][1])+",width="+winVars[winNum][2]+",height="+winVars[winNum][3];
windows[winNum] = window.open( "level"+winNum+".html", "myWindow"+winNum, windowFeatures);
windows[winNum].moveTo(winVars[winNum][0],winVars[winNum][1]);
}
all my windows properties are stored in arrays
to close a window I use : closeWindows(0); // 0 being the number of the window I want to close.
function closeWindows(winNum2){
setTimeout (widows[winNum2] = window.close(),50);
}
Actually I had a bit of confusion beetween parent windows etc...
using "window.opener.popUp(myPopup)" did fix the issues
some changes have been made on the github repo, if you have the same issue you can still refer to the github repo.
Cheers
As a general rule, using multiple browser windows is a Bad Idea, because it's exactly the same interface that all sorts of browser malware uses, such as pop-ups and pop-unders. It's entirely possible that's why you're getting the behavior you're seeing, in fact.
Instead, since you want multiple tiles, just use absolutely positioned div elements.
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 have a requirement to have some modal popups appear on a webpage. At first i implemented them as true modal windows, but then i found out that true modal windows cannot communicate with parent window in IE.
Now i am trying to implement them as regular windows that always steal focus, which is sorta working.
Here is the code that i am using:
modalPopup = window.open(url, 'popup', arr.join(",")); //use a global var here
modalPopup.focus();
$(window).bind("focus.modal", function(){
if(modalPopup){
modalPopup.focus();
} else {
$(window).unbind("focus.modal");
}
});
There are several things wrong with this:
In firefox, once i close the popup, the modalPopup does not become null, it points to parent window. (this is ok, since we dont support firefox anyway)
In IE, it works like a charm when you open 1 window and close it, but opening any more windows results in the exception:
Error: The callee (server [not server application]) is not available and disappeared; all connections are invalid. The call did not execute.
edit: In IE the error happens when modalPopup.focus(); is called. apparently modalPopup is never set to a falsy value when closed :P
Can you help me write a better implementation that uses window.open for creating the popups?
Before anyone says anything, using lightbox is not an option. The popup windows contain A TON of html, javascript etc, and loading them in the DOM is not going to result in a good UX. Also, we sorta have to have this work on IE6.
The windows containing a "ton" of JavaScript, HTML, etc. isn't a reason that you can't use "lightbox" style techniques (which do work on IE6; I don't know if a specific library you've looked at doesn't). The technique is simple:
Have an absolutely-positioned iframe on the page whose z-index is higher than any other content normally shown on the page. Normally the iframe is hidden.
When doing a "modal," show that iframe and set it to cover all other content. Create an absolutely-positioned div with a higher z-index than the iframe and place it wherever you want (typically in the middle of the viewport).
Put your "modal" content in that div. This can be pre-loaded, or you can demand-load JavaScript and other resources to fill it.
Have a UI control of some sort on the div that "closes" it by removing the div and hiding the iframe.
You can build very rich UIs with this that (can) have a dramatically better UX than enforced multiple windows. And you have the advantage of avoiding cross-windows communication and potentially offering much better response time to the user when they "open" one of these windows.