Community
Participate
Working Groups
Created attachment 188946 [details] Display:none issue in a reproducable format. I've been working on a landing page for Orion where I am embedding the editor on to the page and having hidden by default. I'm getting an error "style = null" on editor.js @ line 2926. See attachment for code that causes this error.
I will add that this code does work in Chrome. Also here are my browser versions. Firefox 3.6.13 Chrome 9.0.597.94
I will take a look into this problem. Right now the editor is installed synchronously when the constructor is invoked. In another words, you can call any method in the editor right after it turns from the constructor. I suspect the browser will not load the iframe created by the editor while display=none in parent. To fix this we will probably have to make the constructor asynchronous and add an on load event. This sort of breaks the current API but I don't see any other way. Note: I think this same problem also happens when the parent is not connect to the DOM when the constructor is created.
any progress?
Hi Adam, there are two different problems that cause the textview creation to fail. 1) One of the ancestors has display:none 2) One of the ancestors does not have a parent We have a workaround for case (1), basically we flip display:block in all the ancestors, create the textview, change back display to original state. Can you please confirm that case (1) is the problem for you ?
that might cause some flicker/jiggling. I suppose you could position the element off screen, but still it seems like that could have unintended consequences. Is there some lazy loading / init you can do instead?
(In reply to comment #5) > that might cause some flicker/jiggling. I suppose you could position the > element off screen, but still it seems like that could have unintended > consequences. We wrote the code and we didn't see any problems, but we agree that is can cause trouble. > Is there some lazy loading / init you can do instead? The problem is that in the textview we do not know when to run the initialization code. There are no events we can use. Our best shot was using DOMAttrModified to check for changes in the style attribute and checking if all parents are visible, but that didn't work on IE8. In IE8 we would need extra code using propertychange in every parent. Not pretty. Do you have any suggestions ? See Bug 349627
This problem has been logged against mozilla as well. getComputedStyle() only fails inside a iframe. https://bugzilla.mozilla.org/show_bug.cgi?id=548397
and we're definitely putting the editor in the DOM (in a dijit.layout.TabContainer, but the tab does not remain active). It's not display:none, but I think it's visibility:hidden. Is that the same problem?
worst case, you could leave it up to the developer to trigger initialization, perhaps as an option. I could wire such a method to the tab controls to fire the first time, if need be.
(In reply to comment #7) > This problem has been logged against mozilla as well. getComputedStyle() only > fails inside a iframe. > > https://bugzilla.mozilla.org/show_bug.cgi?id=548397 Yeah, and as Boris Zbarsky said there, it is expected behavior. An element with display:none, and its children, do not get their styling information computed. (In reply to comment #6) > (In reply to comment #5) > > that might cause some flicker/jiggling. I suppose you could position the > > element off screen, but still it seems like that could have unintended > > consequences. > > We wrote the code and we didn't see any problems, but we agree that is can > cause trouble. > > > > Is there some lazy loading / init you can do instead? > > The problem is that in the textview we do not know when to run the > initialization code. There are no events we can use. Our best shot was using > DOMAttrModified to check for changes in the style attribute and checking if all > parents are visible, but that didn't work on IE8. In IE8 we would need extra > code using propertychange in every parent. Not pretty. > > Do you have any suggestions ? > > > See Bug 349627 Thoughts: - This is a somewhat different problem from what I reported in Bug 349627, and even what I reported seems to have two different issues (one that was quickly fixed in Bug 349714). - Nonetheless, code is intertwined and one needs a common solution to the problems. It would perhaps be desirable to have an async mechanism for TextView initialization such that it would avoid potential problems, including what's reported here. The user shall initialize the editor only when it becomes visible. That would not be a bad case, in my view.
*** Bug 334587 has been marked as a duplicate of this bug. ***
Fixed in latest. The fix was to initialize the editor asynchronously when it is hidden because of display:none. The editor loads its content in the iframe only when it detects it is visible using DOMAttrModified. The initialization is also asynchronous if the editor parent is not connected to the DOM. See bug 349627 for more info. If the editor becomes hidden (or disconnected) after its creation, the iframe contents is unload. It will be loaded again if the editor is shown (connect). During the time the editor contents is not loaded, any APIs in the editor that require the DOM will have undefined behaviour. They might throw exceptions. There are APIs that are valid while the editor is not loaded. For example: getText/setText addRuler/removeRuler addEventListener/removeEventListener getRulers getActions setAction setKeyBinding getCaretOffset/setCaretOffset -> no scrolling getSelection/setSelection -> no scrolling setModel
