Tweet
Is it just me, or does the WYSIWYG editor not working in the latest version of FF?
-
-
No, same probleme hereOriginally posted by ogden2k
Identify:
Code:Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040911 Firefox/0.10
===> http://www.vbulletin.com/forum/bugs....iew&bugid=3373Last edited by Keiko; Mon 13 Sep '04, 2:29pm. -
Dammit. I just upgraded too.
Comment
-
Quick fix:
about:config in Firefox address bar.
Search for general.useragent.vendorSub
Set the number to 1 (it's probably set as 0.10).
The reason this fixes it is thus:
Something in vBulletin clientscript does browser detection based on version number.
That code perceives 0.10 as 0.1, and for whatever reason vBulletin then decides that a Mozilla browser with that version isn't full featured, so chooses to downgrade the WYSIWYG entry box to an Enhanced entry box.
0.10 is being perceived as a number rather than a minor version increment.
So 0.10 is zero point one and not zero point ten to vBulletin.
Changing it to 1 makes vBulletin realise that it is a higher version than 0.9, and solves the situation.
vBulletin need to offer a fix to correctly determine browser version.
To resolve it going forward, this should be done on object detection in JavaScript (of the objects needed, rather than known for a browser version) rather than examining the User Agent.Comment
-
Well we can't do object detection since it involves servering another page. Ie. the standard editor rather than the WYSIWYG editor. I'm sure alot of people would be upset if they loaded the page to be redirected to another page a few seconds later.
Or if page sizes suddenly doubled as we needed to give the user the content of both as a fallback.
Mozilla Firefox didn't support WYSIWYG until 0.7 hence why 0.1 is causing an error.Comment
-
Maybe the session table could have additional columns added relating to browser functionality? This way the detection could be done on session creation, and stored for other hits to read?
This is just a quick thought, dismiss it at leisure
Comment
Comment