I was wondering the differences between nsIDOMWindow (returned by Services.wm.getWindowEnumerator and nsIXULWindow returned by Services.wm.getXULWindowEnumerator.
The reason I ask is because i heavily use the windowListener (https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIWindowMediator?redirectlocale=en-US&redirectslug=nsIWindowMediator#addListener%28%29)
I created an example on MDN but don't understand the difference between the two windows. I was thinking if I do i can make a better example.
Thanks
NSIXULWindow is a XUL Application Object Model(AOM) window:
#document
window main-window
...
browser
#document
window myExtensionWindow
Just as HTML is reflected in the DOM as nodes like link, layer, and img, XUL is reflected in the Application Object Model in the hierarchy of XUL widgets: browser, menu, menuitem, and so on. The DOM and the AOM form a kind of continuum, the whole of which is manipulable from the standards upon which XUL is based.
NSIDOMWindow is a HTML Document Object Model(DOM) window:
When a XUL window contains a widget capable of displaying a page, such as <browser> or <iframe>, the document in that widget is, naturally, separate from the document of the chrome window itself. There also is a Window object for each sub-document, although there's no window in a common sense for the sub-document.
The same holds for chrome windows opened inside a tab of <tabbrowser>. The elements above the chrome document opened in the tab are separate from your chrome document.
References
Working with Windows in Chrome code
XUL Bestiary: Object Models - DOM and AOM
XUL Accessibility
Inner and Outer Windows
Related
I understand from documentation and several related StackOverflow posts that window.parent, if there is no other parent, will self-reference and thus never be undefined.
I can't seem to find a decent reason as to why this is. JavaScript does have its idiosyncrasies, but this one just seems odd.
MSDN simply states that
If the current window doesn’t have a parent, i.e. it occupies the whole browser window, Parent returns the current window’s Window object.
MDN states
If a window does not have a parent, its parent property is a reference to itself.
And the W3 standard itself
The value of the parent attribute of a Window object MUST be the parent document's Window object or the document's Window object if there is no parent document
I've not seen other languages acting like this, what reason is there for this self-referencing design? Wouldn't 'null' or 'undefined' make for a more obvious situation when you hit the topmost element in a window?
So, why?
When working with iframes, developers often automate processes which navigate through windows. While the algorithms at their core will consist of the same basic logic, the conceptual approaches will differ.
Instead of working in a parent-children manner, sometimes the developer will craft the system in such a way that it will seem not to look for the parent, but simply for the right window to use. The one that controls (not necessarily holds) the area where the code is currently running.
In the case of such approaches, it would be conceptually weird for the program to return "false" or "undefined" when asking it a refference to the "right" window, because there must be one.
For instance, Bob is programming:
Bob: I embedded an iframe! Alright, let me just play around with the window that contains my entire iframe (not the window of the iframe itself)
Bob: What? Null? But I don't get it, my iframe is up & running, how can there not be any window which controls it?
I'm just saying that window.parent may not be meant to literally and strictly get the parent from the DOM (like .parentElement does), but more like to point to the window which absolutely wraps not only your script, but also everything else that wraps it at lower levels.
In the case of the topmost window (where your script is being executed), that statement may return the same window because, not having any oher window more important than it, it simply becomes 'the right one' to use when looking for the superior container.
I hope I make some sense.
I would say that this helps with window communication. When loading third party content, it might leverage window.parent.postMessage as it's form of communicating with it's implementation context, but it might be implemented with no parent window. An html page loading content in an iframe would have its own window as the iframe windows parent, but content loaded into something like a browser plugin such as an electron webview would have no parent window so the postmessage would fail and the implementing context would not be able to listen for that event. So basically it just allows for a safety net to allow devs to always be able to use window.parent because they might not know if their code will be running from window.top or not.
I assume this is just unfortunate naming. That property could have been better named something like 'parentOrCurrentWindow'.
If what you want is 'parent or current window' then being able to access that as just 'parent' makes your code a little shorter. And if you know that is so then it does not matter much. You could say it is better to get hold of SOME window than null.
But note this has nothing to do with JavaScript the language. This is about the DOM-model implemented by browsers. The DOM model could be improved to include two properties 'parentOrCurrent' and 'parentOrNull'. And in fact you could assign those variables in your own code to make it clear which one you are talking about.
I am developing a gnome shell extension for Gnome 3.4. My extension needs to capture the window events if any editable text is focused in/out.
global.stage.connect('notify::focus-key', Lang.bind(this, this._myHandler));
did not work for me.
Here is a simple use-case: whenever user clicks on firefox search box, I want my handler to be run.
Thanks for any help,
Selcuk pointed me this question, so in order to have this answered here for future search.
The library that would allow to set a global-desktop listener to focus changes is libatspi (the client-side library of GNOME accessibility framework). You could use directly C, pyatspi2 (python manual bindings) or gobject-introspection based bindings (ie, javascript). So a small javascript program that prints name:role_name of the focused object each time the focus change would be:
const Atspi = imports.gi.Atspi;
function onChanged (event) {
log(event.source.get_name() + ',' + event.source.get_role_name());
}
Atspi.init();
let atspiListener = Atspi.EventListener.new(onChanged);
atspiListener.register("object:state-changed:focused");
Atspi.event_main();
In any case, for code examples, you could take a look to recently added focus/caret tracking feature on gnome-shell magnifier (small-size example using javascript) or Orca (GNOME screen reader, big-size example, uses pyatspi2).
libatspi reference here: https://developer.gnome.org/libatspi/
gnome-shell magnifier code here: https://git.gnome.org/browse/gnome-shell/tree/js/ui/magnifier.js
you cannot do this.
application text entry widgets do not fall under the scope of the window manager, so you cannot access their contents, or whether or not they received focus.
GWT screens are composed of a hierarchy of Widgets each implemented by various application classes. In order to maintain (add/change) these screens it is required to understand its structure, namely to discover which screen element is rendered by which Widget implementation.
Currently, I am trying to read the "suspected" class source while peeking at the DOM structure of the screen.
I am looking for a tool, or method, to aid with discovering which Widget class renders a specific screen element.
Such a tool would monitor the mouse position on screen and provide the class name of the hovered element (for example, in a tooltip).
Alternatively, I would be happy to find a programming method that allows adding a generic mouse event handler, most desirable to the RootPanel, further displaying the class name of currently hovered element.
Unfortunately AFAIK ,as of now there is no such tool for GWT( will be more happy if any ) .
As on browser side there is no such information available related to class files of java available since it compiled to javascript.
So , what's the fix??
Though very common and tradational.
1)Proper naming conventions
2)Proper package structure
3)Documentation etc ...
Check out the GWT-Instrumental project for an example of how this can be achieved. This is not a new project and may need to be updated to be properly useful in some cases, but seems to work with GWT 2.4 and GWT 2.5.1 projects just fine. The Inspector bookmarklet/instructions can be found at http://gwt-instrumental.googlecode.com/svn/latest/inspectorwidget/index.html.
This isn't doing exactly what you are describing, but could be modified fairly simply. What it does do is this:
When launched (or refreshed), look at every element on the page to see what widget might be references, and what css classes it has, what id it has, and what DOM events are sunk on it.
When expanded, renders a firebug-like tree of the DOM elements in the body, along with the details mentioned above
When the user hovers over a element in the tree, draws a yellow overlay on where that item is drawn on the page so you can find it.
I'm trying to use a custom video player NPAPI plugin (view FireBreath) inside an tabbed ExtJS application. The plugin lives in one tab, and the others contain presentations of other non-video data.
When switching from tab to tab, the element that contains the plugin is destroyed, and all plugin state is lost. Is there any way to configure an ExtJS tabbed panel so that the html contained in it is not altered when switching to another tab (just hidden)? The alternative is to re-populate the plugin state when returning to the tab, but this would be associated with an unacceptable delay (mostly while waiting for video key frames).
Thanks,
O
I don't know about your ExtJS approach, if you can solve it on that side that would of course be preferrable.
However, if you can't, you can avoid the reinitialization by moving the stream handling to a helper application that is running in the background. The plugin would launch it as needed and receive the stream data from it after registering for it.
The helper would be told when to kill a stream and possibly kill it by itself after some timeout (to avoid session leaks in case of crashing plugins etc.).
I was about to consider a helper application as recommended above, or look into rewriting the plugin to be windowless. Both might be more robust solutions for other JS frameworks.
Fortunately, the solution ended up being simpler than this, at least for ExtJS. By default, ExtJS sets "display: none" on the tabbed view's div whenever it is undisplayed, which calls the plugin destructor. After doing a little more looking through their enormous API, ExtJS has a parameter hideMode as part of the Ext.panel.Panel base class:
'display' : The Component will be hidden using the display: none style.
'visibility' : The Component will be hidden using the visibility: hidden style.
'offsets' : The Component will be hidden by absolutely positioning it out of the visible area of the document. This is useful when a hidden Component must maintain measurable dimensions. Hiding using display results in a Component having zero dimensions.
Defaults to: "display"
Setting the parent Panel that contains the plugin to hideMode: 'offsets' fixed the problem perfectly.
We use MVP with custom EventBus to navigate across the views. One of our GWT module loads an ebook within a view. We have a button named "Expand", which upon clicked, loads the ebook in expanded mode thereby hiding the header, footer, etc.
Let us say the view (UiBinder) with "Expand" button is named as "ShowEbookView". Upon clicking "Expand" button, the ClickEvent is captured and fired to the EventBus. The logic onExpand(final ExpandEvent expandEvent) is written in the same "ShowExpandedMod" class.
Everything is okay, but we have a button named "Popout" in the expanded mode, which when clicked, should open the Ebook in a NEW page! We need to abstract the "ShowExpandedMod" class so that it can operate with the EbookId and can be used in the new page.
We have created a new Module with EntryPoint class, HTML page and UiBinder page for this new popout window. I am not sure how to proceed now with the abstraction and to use EventBus across different modules to load the same content ... (with re-usability ofcourse)
I've explained to my best, but perhaps not very clear! Please let me know if you want more details.
Thanks!
When you open a new window in browser you basically get a new instance of your GWT app. You can not use EventBus across different browser windows, i.e. across different GWT module instances.
What you can do is:
Add an argument to the Popout page URL. This is easies done via "history tokens" (fragment identifiers), like this http://yourdomain.com/popout.html#theIdOfTheDocument. Then you can retrieve the token via History.getToken()
Use DOM to communicate between browser windows: window.open() in javascript opens a new window and returns a reference to DOM of the new window. You can then access properties and functions of the new window. This is all javascript, in order to make this work in GWT you'll need to wrap it in JSNI.
Try and use MVP4G, in specific - take a look at their multi-modules feature (which utilizes GWT's code splitting capabilities).
This should make things like multiple EventBus's and cross-module event triggers a lot easier to handle.