in this function, the div has been bound so it will be referenced as 'this' SetTimeout(setElDisplayBlock.bind(p),10) setTimeout to a function and bind the div to it Var d = document.getElementById('popupWin') #2 You need to set the div display none, delay, and set the div display to block I use this as the outermost div of my draggable popup window: #1 You need to wrap the text elements with a div like whose style is overflow:auto. I have a complex set of potentially overlapping popup divs whose operation was fixed by the following combination: Thanks to all of the work above, I isolated the key fixes that seem to be essential. We now (horrors!) do browser detection, and use IFrames for IE only, which allows our separate workarounds to work on both IE and Mozilla. Voila: a related issue on two platforms that calls for mutually exclusive workarounds. You guessed it-the IFrame on Mozilla will take away the text INPUT cursor, even with "overflow: auto".
One of the only solutions is to slide in an IFrame to cover up native SELECT components on IE. That in itself is not a problem, except that IE uses native window components for SELECT elements, which would shine through the blanket DIV (a situation caused by issues not unrelated to this Mozilla bug). Well, yes and no-and I've found the problem.īehind our floating DIV we were putting a separate blanket DIV to keep user input from the main page, effectively creating a modal popup. > If you make that div 'overflow:auto', you should get the caret.
We can't wait a year to get it fixed, and we need a workaround now for Firefox 1.0x and 1.5. We just started testing a large application for a vertical market that uses AJAX, only to find that all of the popups lose the cursor on Firefox. None of the "workarounds" deal with the more common real-life scenario of having a popup containing flowed content such as an AJAX framework might generate: With AJAX becoming more popular, this is a problem that will be showing up again and again-every AJAX application will want to put up a DIV-based popup containing a text INPUT.Īll of these "workarounds" only "work" for test pages for which you know in advance the exact pixel layout and for which you don't care if it works on IE. After years of complaining about IE's weird requirement of giving controls "layout" to make them position correctly (see ), we find that we have to do something similar (with a similar cause) in Firefox just to get a cursor. That's more than a disappointment-it's inappropriate.
Is there any proposed scheduled release date for version 1.9?
0 kommentar(er)
