I have a TinyMCE editor embedded in a page in which the outer element has an ondrop handler that uploads dropped files.
However, if the user drops a file on the TinyMCE editor, the parent handler is never called. Regardless of whether I enable or disable drag-drop in the editor, the event never propagates to the parent element.
Is there a way to propagate an ondrop event from the TinyMCE editor to the surrounding element?
The editor itself is an iFrame so if you want to propagate the event you need to make sure you are passing it to the parent if you want the page to get the event.
Perhaps you can make a TinyMCE Fiddle or CodePen of what you are doing so people can see what you have tried?
Related
I have a page with multiple contenteditable areas. These are all "inline" editors.
I want to defer initializing TinyMCE until the user actually clicks (or focuses) in one of those areas. How can I activate TinyMCE in response to such an event?
This simplified jsfiddle demonstrates the issue: https://fiddle.tiny.cloud/ibiaab/21
Click in the editor.
Observe that there is no focus event.
Observe that the cursor is not where you clicked.
Click outside the editor.
Observe that there is no blur event.
Observe that the toolbar does not disappear.
After that, things will be ok
In Touch UI, there is an iFrame called Content frame is added.
Can you please tell me
what is the reason of having an iFrame to display the page during the authoring?
There is an observer (/libs/cq/gui/components/authoring/editors/clientlibs/internal/page/js/observe.js) which observes the changes made to the DOM and sends post message accordingly.
What is the reason of sending postmessage and how this is helping?
The AEM developers realized that many problems arose from the fact that edit UI and WYSIWYG content view were rendered into the same context in Classic UI:
Edit UI would push content around, thus making it less WYSIWYG
Content styles could interfere with edit UI, accidentally misplace or hide it
Editor scripts could interfere with content scripts, meaning website authors would need to code around that
Edit UI inserts additional HTML element which need to be accounted for in content stylesheets and scripts
Which is why they decided on a better approach for Touch UI:
All content UI would reside in an iframe under the edit UI
Edit UI aligns to the content UI by measuring where it appears, not by inserting DOM nodes into the content
The observer is one of the few scripts still needed in the content UI to notify the edit UI when it needs to update its overlays
Which is the event when you set the caret inside tinymce editor? For some reason, Click event works only for the first click. Is there any other event except click?
You could use the focus onActivate event. For a full list of possible tinymce events check out this page and have a look on the right side of the page, there is a list.
I have this page I can only access in the browser. There is a HTML element that only exists during drag&drop, and I want to get / analyze its HTML code in the Inspector / Firebug.. but as soon as I stop dragging, the element is removed.
Is there any way of getting the generated HTML element without wading through the JS source that builds it?
EDIT: got it, using the ctrl+S shortcut in chrome to save the page while holding mouseDown with the dragged-element did the trick.
Firebug html inspection shows the HTML of the page real time, so it does show changes caused by interaction. The trick is probably to scroll the inspection panel to the section of the HTML where your drag element appears. That way you would be able to see it while you drag.
I'm trying to use Firebug to inspect a page element that appears when I hover over a photo.
Problem is, the element's position is dynamically offset from the mouse position, so it's impossible for me to right-click on it to get the "Inspect Element" option.
I had hoped that the onhover element would be inserted into the DOM in a sensible place, but so far, I haven't been able to find it.
Any suggestions?
If you know where in the DOM the new element will be created (quite often those elements are created as children of the body element) you can set up a breakpoint for when it is created.
Let's assume that the element will be created as a child of the body element. You will be able to inspect the element if you follow these steps:
Load the page
activate FireBug's HTML panel
Locate the body element
Right-click on the body element and choose Break on Child Addition or Removal from the popup menu
Go hover over your photo to trigger the wanted element's creation
Script execution should then break as soon as the element is created. At that point you will have all the time you need to inspect that dynamically created element, even in the HTML panel.
This isn't an ideal solution, but you could investigate the onhover code to find out more information about the element that's being created. That info might allow you to find it in Firebug's DOM viewer.
Can you search for the element using the search bar at the top of the firebug window?
You can use CTRL+F to find it in the code view.