Dialogs not working on firefox 3(i know, i know, but ...)

[guest]

not sure if it's intended behaviour in firefox or a bug but the latest nightlies fail

with "setting a property that has only a getter" in popups/popup.js line 57

window.dialogArguments = opener.Dialog._arguments;

when opening a popup window(insertlink/image)

clicking on "ok"/"cancel" gives a opener.Dialog._return is not a function errors

maybe this is just a bug in firefox(which you should probably file in bugzilla or risk your editor to suddenly stop working when firefox 3 is finally released),

BUT the whole parameter passing scheme you are using is very ... well ... weird.

it just feels unnatural first have to copy the parameters into the window namespace before being able to use them. also the submission of the new parameters feels less elegant compared to the tinyMCE or even the FCKeditor api(which i don't like very much otherwise)

maybe a new api could be added(while keeping the old one for backwards compatibility) ?

i wrote/am maintaining the switchable editor integration in eXponent cms and soon the my own rewrite eXp2 and Xinha with it's strange (plugin) init and the problems mentioned above gives me so much headaches that i recently started playing with the thought of dropping support.

please don't let that happen, afterall the editor's ui and functionality is valued by many users, just it's apis suck, but that seems fixable, correct ?

[ray]

fixed rev [929]

I know the API is not so well designed (legacy code). The parameters are read from window.dialogArguments following a scheme introduced in IE4 with the function showModalDialog(). The use of this function to show the Xinha dialogs has been abandoned long time ago, for reasons unknown to me. Now, whyever, Mozilla has implemented this function in FF3 and made window.dialogArguments a readonly property.

In this fix I reactivated showModalDialog() for browser that support it (IE & FF3). In terms of not breaking existing plugins that use window.dialogArguments this seemed the best solution to me.

[guest]

I still have this problem in FF3 - using the latest nightly (2008-01-14)

[ray]

rev [939]

I found this was not fixed in ExtendedFileManager. I hope this is what you meant.

[guest]

I have this problem in my custom plugin - i thought this was a problem in popup.js? has it been fixed in popup.js or does it need to be fixed in the plugin?

[ray]

no, it should be fixed for all plugins in popup.js. I will close this once again, as I have tested all (most) of the plugins we have and they work. If you still have problems, we might solve it when you let me have a look at the code in question