I have a Backbone application that appends elements to the DOM. When I log these DOM elements to the console, they sometimes appear greyed-out and isolated in the Firebug inspector, like this:
http://cl.ly/0N0s451G0W2L0x0r072r
Other times, they are shown in full colour and within the context of the DOM. Here is the same element, at a different time in my Backbone app:
http://cl.ly/2k2j0I3g2D0R0K121i3t
I'm guessing that a greyed-out, isolated treatment denotes an element that is not appended to the DOM—but I'm troubleshooting a bug in my app and it would be helpful to be 100% sure.
You guessed right. That "greyed-out" element is detached from DOM.
Related
The code posted by vijayscode (https://stackoverflow.com/questions/34850038/tinymce-4-not-working-with-sortable-jquery-divs/59896435#59896435) doesn't work for me.
TinyMCE doesn't work even before I start ordering. Does sorting work with TinyMCE in when using inline mode?
For example, if I add the inline: true option to this code ... TinyMCE is not loaded immediately
http://fiddle.tinymce.com/33faab
Can you show me a working example on http://fiddle.tinymce.com/
You are really asking two questions so let me try to answer them separately...
Inline Mode
In order to use inline mode you need to target a block element (e.g. div) on the page as opposed to a textarea. This is explained in the documentation:
https://www.tiny.cloud/docs/configure/editor-appearance/#inline
If you want to use TinyMCE in inline mode you will need to adjust your HTML accordingly.
Sorting
As is discussed in SO post you linked to the act of dragging and dropping parts of the DOM impacts TinyMCE because the underlying DOM element that is linked to TinyMCE technically gets removed from the DOM when you start dragging and then a new element is inserted when you perform the drop. Because of this what you want to do is remove() TinyMCE before the DOM element is removed and then init() again after the new DOM element is placed back into the DOM.
I would not recommend using the mceAddEditor and mceRemoveEditor to do this work. Instead I would:
Call remove() to detach TinyMCE from the DOM element.
Let the drag/drop complete
Call init() on the DOM element after its placed back into the page.
Calling init() after the element is back in the page would allow you to determine the element's class/id/etc and call init() with the correct configuration.
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.
Firefox addon. I'm porting an existing addon to a restartless one. I have a panel with a lot of UI elements (mostly boxes/description and images) in it, and it is very convenient for me to define the panel elements in an XUL overlay file. I will have lots of bloated js code if I don't.
The panel element (parent) itself is created in code dynamically, and then I use loadOverlay, wait for the 'merged' event and then append the panel element's children from the overlayed document. I also make sure that the elements are cleaned up upon a remove.
However, using overlays will most probably won't pass an AMO review. And some of the reasons I think are :
In most cases overlay elements will cause problems while removing (eg: toolbar buttons remembering their positions etc.)
There are problems with attaching js/css files in an overlay file.
loadOverlay is buggy (496320, 330458)
And here are my inferences :
loadOverlay() API itself is not deprecated - in fact it is 'not frozen and may change later' - which means possibly it will be use-able in future.
The bug that a second overlay load fails, is not applicable in my case, as I don't initialize without an overlay merge.
Using static overlay for preference windows etc. is perfectly acceptable as of now.
The panel in my case behaves a lot like a preference window (which is brought up on demand and cleaned up upon addon removal)
I don't have any js/css attached to the overlay, nor any event listeners for the elements. The overlay is only used to define boxes and description text - nothing more.
So considering these, is it acceptable to use overlays and loadOverlay() for a restartless addon ? If not, is there an alternative ?
About overlays, by checking source code of restartless addon that extend existing addon (like ehh), I see the overlay.xul is auto merged with the existing addon's. So it shouldn't be a problem to use overlay.
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.
The object is to Show-Hide text located under their respective Titles, so a User reads the title and shows or hides text belonging to that title if the User wants to read more.
I tried whatever I could find so far on here, we're talking dynamically setting text coming from a spreadsheet, can't use IDs, must work with .class, must be missing something, I have this piece of code:
... html.push('<div class="comments">' + comment + '</div></div></div>');
but when I try this Show-Hide code nothing happens, even if the error console shows nothing. Basically I want to Show-Hide the .comments class divs with a show-hide toggle link located under each of them. I say them because the .comments divs are reproduced dynamically while extracting text coming from Google spreadsheet cells/row (one .comments div per spreadsheet row). I tried .next, child and parent but they all divorced me so I dunno looks like a dynamic issue. So far I only managed to globally toggle all divs to a visible or hidden state but I need to toggle independantly individual divs.
I prefer a jQuery solution but whatever worked so far was achieved with native javascript.
Note: If a cross-browser truncate function which would append a more-less link after a number of words (var) in each .comments divs would be easier to implement then I would gladly take that option. Thx for any help, remember I am still learning lol!
I have been working on an entirely JS UI project and have brought myself to using $('', { properties }).appendTo(BaseElement) to work best for adding HTML elements because it appropriately manipulates the DOM every time.
If you are having good luck with push elsewhere, however, breakpointing on the line where you do your $('.class').hide() and see what $('.class').length is. Alternately, you can just add alert($('.class').length) to your code if you are unable to breakpoint the code. If it is 0, then your elements have not been properly added to the DOM. Changing to append will ensure they are part of the DOM and therefore targetable via JQuery.