TinyMCE & CKEditor: IE/Chrome: Buttons do not wrap

This looks like wysiwyg_editor.css is not loaded - can you verify this?

My question was whether wysiwyg_editor.css is actually loaded on the page the editor is loaded - please look in the HTML output to check whether the file has been referenced in the header.

Additionally, which browser and browser version on which platform are you using? Are you able to replicate this bug with a different browser / platform?

@ISchier770: Thanks for resetting everything. If you think that your issue will get more attention by setting its state to arbitrary values, then you make wrong assumptions. The previous state was set intentionally. See Status levels of Issues and Priority levels of Issues for further information.

I am not able to replicate this bug report.

Marking as duplicate of #277954: Allow to sort editor buttons

umm..sorry for reopening this, but while with TinyMCE 2.x buttons tended to wrap on a second line and respect main region width, with Tiny 3.x all the buttons are displayed on one long single line breaking the page layout as reported by ISchier770.

maybe making them wrap is lot easier than allowing (ajax) sorting of buttons as is asked in #277954

PS: wysiwyg_editor.css DOES load. maybe the fix to this is just a small .css tweak *having a look*

EDIT: this is likely to be the Toolbar much more structured into a table in TinyMCE 3.x (editor_ui.css). Needs a deeper look..

Yes. The obsolete TinyMCE module for Drupal did not allow to sort editor buttons and placed them onto arbitrary locations instead. So the quick fix was to remove that code and stack all buttons into one row and aligning them via CSS afterwards.

Correct, wysiwyg_editor.css contains TinyMCE 2.x specific styles only. Another quick fix would be to just add the necessary styles for TinyMCE 3.x.

The proper, long-term fix is to define "css path"/"css file" in the editor definition, separately for each version of TinyMCE.

I would accept a patch that solves this in one of both ways, preferring the latter of course.

If someone can fix this, I can pay a good amount per hour. Please get in touch through my contact form at http://drupal.org/user/4131/contact with a quote. Thanks.

Attached patch re-aligns all buttons for TinyMCE 3. First iteration. I'll work on the proper fix now.

And here comes the proper solution, moving editor specific CSS stylesheets into their own files. Nice.

Committed to all branches. A new development snapshot will be available in approx. 12 hours.

Hi,

Just checked latest build and the buttons toolbar in TinyMCE using Firefox 2 is broken. See attached screenshot.

It looks like TinyMCE still builds the toolbar based on theme_advanced_buttons1, and plugins seem to use this information as well to display popup layers. See colorpicker in screenshot.

Attached patch should fix this.

Next time, please re-open the issue.

Buttons float correctly on Firefox 3.

However, it happens something curious now. I'm using 1280x1024 resolution, so the TinyMCE textarea is quite wide. If I resize the browser window to 1024x768, then the TinyMCE textarea keeps its width and so it gets wider than page (Garland them, fluid layout). Please, see attached screenshot tinymce_textarea_crossing_page_edge.png.

When I start to edit at 1024x768 and then resize the browser window back to 1280x1024, then the TinyMCE textarea keeps its width, and so, it gets thick compared to the new page width. Please, see attached screenshot tinymce_textarea_leaves_empty_space.png.

This effect doesn't happen here:
http://tinymce.moxiecode.com/examples/full.php

ie. the whole text area is resized when the browser window resizes.

That's a different issue. Quick inspection tells that they are setting width: 100%, and the default width is set based on the textarea that has been replaced: http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/width - please open a new issue for this.

Thanks, committed.

Hello,

Within IE7 all the buttons are on one line like it was the case with the first poster.
Now within firefox the buttons appear like they should.
TinyMCE version 3.2.1.1.

What could cause this?

I believe this is an issue with IE 7 and how it interprets the CSS "display: inline" for td table elements. Firefox treats inline correctly for the specification and the table cells act as if they are characters and rap properly. IE 7 ignores the inline option for td (cell) table elements and creates one long line. I've spent a little time trying to find a CSS option that will make IE work but to no avail. Part of the problem is that TinyMCE is using a table to display its buttons making it hard to do easy CSS formatting. Maybe someone with a better handle on CSS/IE quirks has an idea to make this work.

Short of someone with a CSS fix for IE or a change to the way TinyMCE's HTML is configured to display its buttons, I expect that we will have to wait until the coding in WYSIWIG API to configure button placement is finished.

I can confirm this is happening for Google Chrome with the latest version as well.

@spiffyd: Could you please stop assigning arbitrary statuses and priorities for issues without adding any valuable information to them? Thanks.

a) This is a bug in 6.x-0.5.

b) This is not critical, as you could simply use a different editor to circumvent this issue. It also does not completely break your site.

c) If you alter the issue title, only alter it if you are absolutely sure that the new title is 100% more accurate.

Subscribing. I am also having this issue in IE7 and Chrome. Not sure about IE6 because whenever I open my Drupal site in IE6 it crashes hard and I usually need a reboot, lol - not sure what fun combination of modules or whatever might be causing that...

@livingegg: See #352938: TinyMCE 3: IE6: Memory leak with Forecolor button

I'll be watching this one too. I've got a userbase that loves their IE7, and while I can pass off IE6 as "not modern/not supported", I can't really do the same for 7.

=/

I just threw an ugly hack into WYSIWYG API's tinymce.inc. It starts at line 243, which should start with "// @todo Allow to sort/arrange editor buttons."

If anyone is in dire need of something immediate while they wait for a real fix, this can temporarily solve the problem and brings IE7 (and I assume Chrome) to a usable state. Obviously, this is specifically tailored to the buttons I'm using. Your own buttons may need to wrap sooner or later than the points I've designated. Find out the button name and change the check inside the if, as needed.

// Setting up the ability to drop down a line when a certain button is encountered
$line = 1;
for ($i = 0; $i < count($init['buttons']); $i++) {
  $current_button = $init['buttons'][$i];
  // If one of these buttons is up for insertion, we need to drop to the next line of the editor layout
  if($current_button === "formatselect" || $current_button === "tablecontrols")
    $line++;
  $init['theme_advanced_buttons'.$line][] = $init['buttons'][$i];
}

I tried to debug IE's weird behavior for some hours now. It seems like it does not understand display: inline for table cells (TD) at all.

So we need to implement the sorting and placement of editor buttons (see the other issue).

Reverting status to closed. If someone steps up with a working solution that is not a hack (like the previous suggestions), then feel free to re-open this issue. In general, I'd like to see more traction on the other issue though.

subscribe

(Edit: I thought I made this in reply to #29 -- http://drupal.org/comment/reply/308912/1202840#comment-1202840 -- but it seems to be its own thread)

Brilliant!

Excellent hack...

Though for me, the line started around 250...

replacing the code here (for anyone confused about where to place the hack)...

// commenting out the following 3 lines for "quick fix"
//for ($i = 0; $i < count($init['buttons']); $i++) {
//  $init['theme_advanced_buttons1'][] = $init['buttons'][$i];
//}
// begin "quick fix" from http://drupal.org/comment/reply/308912/1202840#comment-1202840
// Setting up the ability to drop down a line when a certain button is encountered
$line = 1;
for ($i = 0; $i < count($init['buttons']); $i++) {
        $current_button = $init['buttons'][$i];
        // If one of these buttons is up for insertion, we need to drop to the next line of the editor layout
        if ($current_button === "hr" || $current_button === "formatselect" || $current_button === "print")
                $line++;
        $init['theme_advanced_buttons'.$line][] = $init['buttons'][$i];
}		
// end "quick fix"

I've implemented this fix and although it succeeds in breaking after the right amount of buttons, it throws up another problem.

After my first 11 buttons I have the "Table" check box selected, but instead of displaying the Table buttons it just displays four separators.

I've tried this fix: http://drupal.org/node/277954#comment-1213013

And the same thing happens. Can anyone advise as to why?

Thanks.

edit: The Table buttons display in Chrome but not in IE6,7,8 or in FF2 and 3.

I started from scratch and somehow eliminated this issue.

This fix did it: http://drupal.org/node/277954#comment-1239825

Re-opening this issue, since #277954: Allow to sort editor buttons will take more time than I initially thought to get resolved.

Please test attached patch. Works for me in FF and IE. Didn't test Chrome and Safari.

Minor fix.

Hello I'm under Drupal 6.9 and windows.
I juste tried to apply the patch after looking how to do that under win32 but the patch application just failed, terminating the patch process.
I'm not able to go further in patching without wasting more time.
I will just wait for a new version of this great API.

Thanks for the patch, hope someone else will succeed, I will just continue to use the basics buttons under tinymce.

I'm experiencing this issue in 5.x-1.0. Is it possible to backport this patch?

Patch should apply without any issues to both 6.x-2.x and 5.x-2.x.

Subscribe

Really, this patch worked pretty well based on my own testing. Could at least someone confirm? See http://drupal.org/patch/apply for further information - don't worry, it's very simple to test patches!

I am working with the latest stable releases of: imce, imce-wysiwyg, and wysiwyg api
Was experiencing this bug on IE6. I manually applied sun's patch at #36 and the problem has been fixed.

Thank you for the patch, hope it gets committed soon.

@midkemia: Did you clear your browser's cache? Most probably your browser did not load the updated JavaScript.

Good. Someone able to test on Chrome?

Committed to all branches.

Patch in #36 worked for me with IE7, Drupal 5.16 and WYSIWYG 5.1 with TinyMCE 3.0, thank you sun. :o)

Note that this fix is already contained in all latest development snapshots of Wysiwyg API, i.e. also in 5.x-1.x-dev.

Thanks sun
indeed the problem is fixed in the 6.x dev version

I just had the same "not wrapping" problem with the last dev version 6.x-2.x-dev, tinyMCE 3.2.2 and Chrome as my browser.

@faunapolis: Did you update to the latest development snapshot? And did you ensure that your browser loads the updated JavaScript?

I just upgraded to 6.x-1.1 - using safari, it previously didn't wrap on the inline editor - that's now fixed. It's still not wrapping in the full screen editor - presumably the fix just needs porting across?

Huh? What kind of "full-screen editor" are you talking about?

@sun

Wysiwyg 6.x-1.1 with TinyMCE 3.2.2 comes packaged with the TinyMCE fullscreen plugin: http://wiki.moxiecode.com/index.php/TinyMCE:Plugins/fullscreen .

Turning this plugin on adds a fullscreen button to the editor's button bar, which, when pressed, enlarges the text box to fill the entire browser window. The button bar remains at the top (or wherever it is set to display, I guess), and the whole screen looks a bit like google documents, or word, or something like that.

See attached screenshot of full screen mode, on Safari 4 (Public Beta (4528.16)). This browser had the same layout problem as IE with Wysiwyg 6.x-0.5.

@ged3000: Sorry, this cannot be resolved in this issue. You have to wait for #277954: Allow to sort editor buttons.

All we can fix in this issue is compatibility with Chrome. However, I will close this issue if no debug information is provided within 3 days.

Sorry for reopening:
I have the same problem with the button bar (on FF 3.0.6), I have installed on Drupal 5.16 Wysiwyg API 5.x-1.1 and TinyMCE 3.1.0.1.
But, instead of the tinymce-3.js in the head of the page you can see:
<script src="/sites/www.mysite.it/modules/wysiwyg/editors/js/tinymce-2.js" type="text/javascript">.
But in the Wysiwyg page settings the Full HTML Wysiwyg profile is set on TinyMCE 3.1.0.1.
Thanks

@kikko: Based on the information you provided, that's a completely different issue. Please open a separate issue.

Ok, thanks and sorry

Decision taken. Please open a new issue for Chrome, if it is still an issue at all.

I can confirm this is definitely still a problem, after a couple hours of testing:

Testing with:
Drupal 5.12
Firefox 3
IE 7

- Config 1
TinyMCE 3.2.3.1
Wysiwyg 5.x-2.0-alpha1

Broken for IE7, toolbar does not wrap. wysiwyg.css is not loaded with the page (tested in Garland, other themes, same problem)

- Config 2
TinyMCE 3.2.3.1
Wysiwyg 5.x-2.x-dev (2009-May-20)

?q=admin/settings/wysiwyg/profile doesn't even recognize that there are any editors installed

- Config 3
TinyMCE 3.2.3.1
Wysiwyg 5.x-1.x-dev (2009-May-20)

Broken for IE7, toolbar does not wrap. wysiwyg.css is not loaded with the page (tested in Garland, other themes, same problem)

editors/js/tinymce-3.js DOES contain the patch in 36 above, however the toolbars are still broken in IE and work fine in Firefox.

Subscribing.

Buttons do not wrap for me in fullscreen with Chrome.

In my case in fullscreen the window is too wide and not everything on the right is shown (buttons and content)
Didn't find a way to fix it :x

wysiwyg 6.x-2.1 (2010-Mar-08) ckeditor buttons are still in one row.

instead of manipulating the code for "quick fix" as in #29 & #32 above, I just added the following css:

a#cke_25{display:block;}

having a single button on a row is probably not nicer, but code-wise I think it is a cleaner "quick fix"

Confirming that buttons don't wrapped in IE 7. Windows XP. Using Wysiwyg 6.x-2.1

#65 temporary fix works for me. Thanks monti :) I'm using CKEditor and Wysiwyg 6.x-2.1

Confirming this is still an issue with:
* IE 7 or Google Chrome 6
* Windows XP
* Wysiwyg 6.x-2.1

For details find above #66 and #67

Steps to reproduce this issue:
1. Go to /admin/settings/wysiwyg/profile/*/edit
2. Under 'Buttons and plugins' section check all boxes
3. Test. All buttons are in one row. Expected result is buttons should wrap.

Subscribing.

Subscribing. It happens with me in
Drupal 6.19
Wysiwyg 6.2-2.3
TinyMCE 3391
Win XP
In IE and in FF

Sorry it is different. By changing the width value in tinymce.inc I can make the box smaller and then the buttons do wrap. Min appear to be another problem: No matter what width I choose, I keep having a horizontal scrollbar below. So I never get to see the full width of the text. Do not know if this is a Wysiwyg thing or a Tinymce thing

I consider this issue a duplicate of #277954: Allow to sort editor buttons since the problems here are caused by Wysiwyg module currently forcing all buttons to be on a single row or even in a single group. CKEditor button groups are supposed to be kept together on the same row and jump down as a whole when there's no room for that. TinyMCE gets similar problems when only one row is used.

All we can do here without fixing the above issue is to provide hacks and workarounds that will further complicate things.

Could anyone who's got some spare time please help test the latest patch in #277954: Allow to sort editor buttons so we can fix the root cause of these toolbar problems?