Closed Bug 494883 Opened 15 years ago Closed 15 years ago

unable to switch between Visual and HTML editor in Wordpress 2.7.1 (e is undefined in tinymce code)

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
1.9.1 Branch
Platform:
Other
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 494143

People

(Reporter: deb, Unassigned)

Details

Trying to post the newsletter using Shiretoko-latest this morning, I discovered that I was unable to flip between the "Visual" and "HTML" tabs on the Wordpress 2.7 "Post new" page.  This happened in my standard and a new profile, and does not happen in a new profile on beta4.  Almost 100% certain that it was not a problem last Tuesday, but have not had a chance to dig back to find a regression range at this point.  (Will do so later if i have a chance.)
Flags: blocking-firefox3.5?
I can confirm this on a recent 1.9.1 build, using a couple of different wordpress installs.  Attempting to switch editors from Visual to HTML (or vice versa?) just results in a broken, empty edit dialog.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090526 Shiretoko/3.5pre
May be related to, or a dup of, bug 494143
When I load the page I get:

Error: e is undefined
Source File: https://developer.mozilla.org/devnews/wp-includes/js/tinymce/tiny_mce.js?ver=20081129
Line: 1

Possibly related to bug 494143 - the reporters in that bug seem to start in HTML mode, and it's unclear if they've tried switching between the modes with any success.
Assignee: nobody → general
Component: General → JavaScript Engine
Flags: blocking-firefox3.5?
Keywords: regressionwindow-wanted
Product: Firefox → Core
QA Contact: general → general
Summary: Major wordpress bug in Shiretoko → unable to switch between Visual and HTML editor in Wordpress 2.7.1 (e is undefined in tinymce code)
Version: 3.5 Branch → 1.9.1 Branch
Flags: blocking1.9.1?
Confirmed in Windows as well --> All

Also, this is branch-only; we can't reproduce it on trunk nightlies (I tried Windows, Blizz tried OSX)
OS: Mac OS X → All
Flags: blocking1.9.1? → blocking1.9.1+
This worked on revision f9fdf276d414 on mozilla1.9.1, meaning there's a preliminary range of:

http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=f9fdf276d414&tochange=8599c60654df
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

Looks like a JS change, perhaps unsurprisingly?
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.