Closed Bug 494143 Opened 16 years ago Closed 15 years ago

icons not available in visual editor mode, unable to switch to HTML editor in Wordpress 2.7.1 and on wordpress.com (e is undefined in tinymce)

Categories

(Core :: JavaScript Engine, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla1.9.1

People

(Reporter: fredbezies, Assigned: brendan)

References

()

Details

(Keywords: fixed1.9.1, verified1.9.1, Whiteboard: [see comment 36 for updated bug report])

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20090521 Firefox/3.6a1pre Build Identifier: Since patch for bug 488649 was added, I cannot have anymore a fully working visual editor mode in my wordpress.com account. A lot of errors are sent, all related to CSS not understood. Reproducible: Always Steps to Reproduce: 1.Grab a build with patch for bug 488649 added 2.Go into a wordpress.com account 3.Edit a new post in visual editor mode Actual Results: Nearly all icons are gone. Expected Results: All icons present. Here is some errors I get : Warning: Unknown property 'border-radius'. Declaration dropped. Source File: http://s3.wordpress.com/wp-admin/css/global.css?m=1242654392b Line: 463 Warning: Unknown property 'box-sizing'. Declaration dropped. Source File: http://s1.wordpress.com/wp-admin/wp-admin.css?m=1242758370b Line: 377 Source code for errors : select { border-width: 1px; border-style: solid; -moz-border-radius: 4px; -khtml-border-radius: 4px; -webkit-border-radius: 4px; border-radius: 4px; } #editorcontainer #content { padding: 6px; line-height: 150%; border: 0 none; outline: none; -moz-box-sizing: border-box; -webkit-box-sizing: border-box; -khtml-box-sizing: border-box; box-sizing: border-box; } A build made before bug 488649 was made is working perfectly. A timerange : Works : Built from http://hg.mozilla.org/mozilla-central/rev/4480c18255f2 Doesn't work : Built from http://hg.mozilla.org/mozilla-central/rev/091e0fa0fa7a
Summary: [trunk] icons not available in visual editor mode. → [trunk] icons not available in visual editor mode on wordpress.com
Flags: blocking1.9.1?
(In reply to comment #0) > Warning: Unknown property 'border-radius'. Declaration dropped. > Source File: http://s3.wordpress.com/wp-admin/css/global.css?m=1242654392b > Line: 463 > > Warning: Unknown property 'box-sizing'. Declaration dropped. > Source File: http://s1.wordpress.com/wp-admin/wp-admin.css?m=1242758370b > Line: 377 These errors are expected; we support these properties only with -moz-* prefixes.
(In reply to comment #1) > (In reply to comment #0) > > Warning: Unknown property 'border-radius'. Declaration dropped. > > Source File: http://s3.wordpress.com/wp-admin/css/global.css?m=1242654392b > > Line: 463 > > > > Warning: Unknown property 'box-sizing'. Declaration dropped. > > Source File: http://s1.wordpress.com/wp-admin/wp-admin.css?m=1242758370b > > Line: 377 > > These errors are expected; we support these properties only with -moz-* > prefixes. the problem is icons were shown without problem before. No more now. Weird.
(In reply to comment #3) >the problem is icons were shown without problem before. No more now. Weird. I know. I'm just pointing out that those messages are not a sign that there's a CSS bug. It might be helpful to have a narrower regression range; I'm not sure why you're convinced it's that particular bug. If you thought it was that bug because you were seeing CSS errors, then it's probably worth thinking again.
I will download every single available trunk builds in that timerange to find when this bug appeared first.
More infos (even if I'm kinda lost) here. Official nightly for 19 may works : Built from http://hg.mozilla.org/mozilla-central/rev/8737a137215c Weird.
And 20 may official build is working too :( Built from http://hg.mozilla.org/mozilla-central/rev/0f4de606acd7 Could it be a gcc 4.4.0 bug ? Will try today's nightly. Sorry for spamming.
Assignee: nobody → general
Component: Style System (CSS) → JavaScript Engine
QA Contact: style-system → general
The ranges in comment 8 and comment 0 are disjoint. Which is the correct range?
The last one is the good one.
Can you still reproduce with jit.content turned off?
Yes, unfortunately. TraceMonkey on / off, the same result :( I tried with Epiphany 2.26.2 => Mozilla/5.0 (X11; U; Linux x86_64; en; rv:1.9.0.10) Gecko/20080528 Epiphany/2.22 Firefox/3.0 and it works. Anyway, I have this in error console about js errors : Error: a is undefined Source File: http://frederic.bezies.free.fr/blog/wp-includes/js/tinymce/wp-tinymce.php?c=1&ver=323 Line: 2 And another error : Error: tinyMCEPreInit.go is not a function Source File: http://frederic.bezies.free.fr/blog/wp-admin/post.php?action=edit&post=2209 Line: 1248 <script type="text/javascript"> /* <![CDATA[ */ tinyMCEPreInit.go(); tinyMCE.init(tinyMCEPreInit.mceInit); /* ]]> */ </script> I cannot paste the source code because it is really big. Sorry :/
Here is the beginning of the compressed js code : var tinymce={majorVersion:"3",minorVersion:"2.3",releaseDate:"2009-04-23",_init:function(){var o=this,k=document,l=window,j=navigator,b=j.userAgent,h,a,g,f,e,m;o.isOpera=l.opera&&opera.buildNumber;o.isWebKit=/WebKit/.test(b);o.isIE=!o.isWebKit&&!o.isOpera&&(/MSIE/gi).test(b)&&(/Explorer/gi).test(j.appName);o.isIE6=o.isIE&&/MSIE [56]/.test(b);o.isGecko=!o.isWebKit&&/Gecko/.test(b);o.isMac=b.indexOf("Mac")!=-1;o.isAir=/adobeair/i.test(b);if(l.tinyMCEPreInit){o.suffix=tinyMCEPreInit.suffix;o.baseURL=tinyMCEPreInit.base;o.query=tinyMCEPreInit.query;return}o.suffix="";a=k.getElementsByTagName("base");for(h=0;h<a.length;h++){if(m=a[h].href){if(/^https?:\/\/[^\/]+$/.test(m)){m+="/"}f=m?m.match(/.*\//)[0]:""}} function c(d){if(d.src&&/tiny_mce(|_dev|_src|_gzip|_jquery|_prototype).js/.test(d.src)){if(/_(src|dev)\.js/g.test(d.src)){o.suffix="_src"}if((e=d.src.indexOf("?"))!=-1){o.query=d.src.substring(e+1)}o.baseURL=d.src.substring(0,d.src.lastIndexOf("/"));if(f&&o.baseURL.indexOf("://")==-1){o.baseURL=f+o.baseURL}return o.baseURL}return null} Don't know if it could help. It is tinymce 3.2.3. http://tinymce.moxiecode.com/
Can be seen too with a 3.5pre nightly build. Using a built based on http://hg.mozilla.org/releases/mozilla-1.9.1/rev/11e0fd20fde9
Summary: [trunk] icons not available in visual editor mode on wordpress.com → [trunk and 1.9.1 branch] Icons not available in visual editor mode on wordpress.com
Yay, another tinymce bug! If you can find the range on the tracemonkey tree, that would be _spectacularly_ helpful. I would make a semi-educated guess on bug 493760.
Flags: blocking1.9.1? → blocking1.9.1+
Try to backing out patch for this bug. Will see if it is the culprit or not. I will try also patches for : - bug 490908 - bug 493657 - bug 493720 - bug 493821 I hope I will find it really soon.
You are a king among men! You might find that http://hourly-archive.localgho.st/hourly-archive2/ helps since it has tracemonkey hourlies.
Well, as there is no linux 64bits builds... And as I am using an archlinux 64 bits, what can I do ?!
(In reply to comment #15) > Yay, another tinymce bug! > > If you can find the range on the tracemonkey tree, that would be > _spectacularly_ helpful. > > I would make a semi-educated guess on bug 493760. Good guess. It is this one. Weird.
Depends on: 493760
Blocks: 493760
No longer depends on: 493760
Just to add getting the same warnings as described in Post 0 in the error console along with tinyMICE errors. I am running the Windows build: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1pre) Gecko/20090522 Shiretoko/3.5pre ID:20090522045120.
Anyone able, please try the patch in bug 494544 -- that bug is not only about let bindings (I'll update its summary now). /be
Do not fix anything. Only reverting patch for bug 493760 fixes the bug.
Assignee: general → brendan
Status: NEW → ASSIGNED
OS: Linux → All
Priority: -- → P1
Hardware: x86_64 → All
Target Milestone: --- → mozilla1.9.1
Could someone from QA reproduce this? We're having trouble.
Keywords: qawanted
Specifically, I can't reproduce it with a fresh wordpress account on tm tip. /be
I can't reproduce on trunk or shiretoko on mac os x. Frederic, can you please attach a screen shot showing the problem so I can be sure what to look for?
Slight chance this is x86-64 only. Anyone else have a box who can test? /be
I'm having the same problem on Mac OS X and two Wordpress based blogs (so, not Wordpress.com). When you open the "Add New" page, the editor load in "HTML" mode, if you try to switch to "VISUAL" you can't see the icons and the original text is not displayed. If you want, I can create an account on one of these blogs to try reproducing the problem.
Francesco: much appreciated, please mail me info and I'll log in and try to debug. Thanks, /be
I can't reproduce this on Vista64 with today's Shiretoko, fwiw.
(In reply to comment #30) > I can't reproduce this on Vista64 with today's Shiretoko, fwiw. Still happening here with Intel Mac OS X 10.5 and Gecko/20090525 Shiretoko/3.5pre I sent the account information to Brendan, I don't know if he's been able to reproduce the problem.
I can also reproduce on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090525 Shiretoko/3.5pre. I'll try and knock up a debug build in a while.
(In reply to comment #32) > I can also reproduce on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; > rv:1.9.1pre) Gecko/20090525 Shiretoko/3.5pre. I'll try and knock up a debug > build in a while. I've just downloaded trunk: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090525 Minefield/3.6a1pre and it works fine.
People experiencing this problem: can you switch between Visual and HTML tabs? We've got a report of that being broken in bug 494883 and are wondering if they're related (it's also all platforms, branch-only, recent regression on Wordpress 2.7.1)
(In reply to comment #34) > People experiencing this problem: can you switch between Visual and HTML tabs? > We've got a report of that being broken in bug 494883 and are wondering if > they're related (it's also all platforms, branch-only, recent regression on > Wordpress 2.7.1) No, you can't switch between Visual and HTML tabs: the behaviour is exactly the one described in bug 494883 (and bug 494559, already marked as a duplicate of this one).
Relevant comments from bug 494883 (which is a little cleaner than this one, fwiw): // What's the error indicating tinymce is failing to load? Error: e is undefined Source File: https://developer.mozilla.org/devnews/wp-includes/js/tinymce/tiny_mce.js?ver=20081129 Line: 1 // What platforms does it affect? All platforms, branch only. // What are the symptoms - no icons in the visual editor - unable to switch to the HTML tab // When did it start happening Busted with d227395c1f93 on 191, so the much-reduced range is: http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=f9fdf276d414&tochange=d227395c1f93
Keywords: qawanted
Summary: [trunk and 1.9.1 branch] Icons not available in visual editor mode on wordpress.com → icons not available in visual editor mode, unable to switch to HTML editor in Wordpress 2.7.1 and on wordpress.com (e is undefined in tinymce)
Whiteboard: [see comment 36 for updated bug report]
Assuming this is indeed the same issue as bug 494883, it appears to have been caused by: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/ddfd1ec7dc02 It's broken on that changeset, but not on the immediately-prior http://hg.mozilla.org/releases/mozilla-1.9.1/rev/3a66a6f4649a
(In reply to comment #38) > Assuming this is indeed the same issue as bug 494883, it appears to have been > caused by: > > http://hg.mozilla.org/releases/mozilla-1.9.1/rev/ddfd1ec7dc02 > > It's broken on that changeset, but not on the immediately-prior > > http://hg.mozilla.org/releases/mozilla-1.9.1/rev/3a66a6f4649a ... which I now see Frederic spotted - ah the advantage of spotting dups early. Apologies for the chatter, folks. If TM guys are still having trouble reproducing, I can give access on my own wordpress instance.
(In reply to comment #31) > (In reply to comment #30) > > I can't reproduce this on Vista64 with today's Shiretoko, fwiw. > > Still happening here with Intel Mac OS X 10.5 and Gecko/20090525 > Shiretoko/3.5pre > > I sent the account information to Brendan, I don't know if he's been able to > reproduce the problem. I have no mail from you, not even in the Junk folder -- best to find me on IRC, in #jsapi, usually authenticated and op'ed. Nick will be brendan, call my name if it's brendan_ and I need to reclaim brendan and authenticate with nickserv. /be
I just updated to http://hg.mozilla.org/releases/mozilla-1.9.1/rev/731679c1ff39 which includes some recent landings from sayrer, and wordpress works again, as Rob suspected it might.
(In reply to comment #41) > I just updated to http://hg.mozilla.org/releases/mozilla-1.9.1/rev/731679c1ff39 > which includes some recent landings from sayrer, and wordpress works again, as > Rob suspected it might. I can confirm this on my debug build which I did earlier today (and it was failing) and updated it and it now works.
Comment 22 seems to deny that the patch for bug 494544 recommended in comment 21 helped, but that is the only followup fix that I know of that was not merged into 1.9.1 until today. If that wasn't the fix, what was? If it was, then the private build referenced in comment 22 must have been missing the fix. /be
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Don't know what fixed the bug, but now, it is gone. As I always try to stay up-to-date (using no 3rd party patch), I am pleased to use a working build ;)
The problem is gone also on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; it; rv:1.9.1pre) Gecko/20090527 Shiretoko/3.5pre Myabe someone should add the verified1.9.1 key?
You need to log in before you can comment on or make changes to this bug.