In Drupal 8.0.0-beta1, given a two-row arrangement of Available Buttons:
To move something out of the active toolbar, it is not enough to drag the button into the two-row rectangle of available buttons. You have to move it before the last available button. Moving an unwanted button, e.g., strikeout, immediately to the right of the Styles button resulted, unexpectedly for me, in no change. I also tried dragging it into the second row of buttons to no avail.
Steps:
1. Go to /admin/config/content/formats/manage/full_html
2. Adjust browser window size and/or zoom of browser such that Available buttons spans two rows
3. Drag the subscript button (x-sub-2) to the 2nd row of Available buttons.
Actual result: Highlighted position remains in Active toolbar
Expected result: Highlighted empty position appears in the Available buttons array, ready to receive the subscript button. No highlighted position in Active toolbar.
Workaround: Drag into the first row of Available buttons. If you still want it to be in the second row, you can now drag it back to that row before releasing the mouse button.
Comment | File | Size | Author |
---|---|---|---|
#10 | drag_to_2nd_row_available_btns-2349303-10.patch | 979 bytes | PQ |
#8 | Screen Shot 2015-09-12 at 16.11.25.png | 413.36 KB | Wim Leers |
#7 | 2349303-7.mov | 3.03 MB | Charles Belov |
Comments
Comment #1
Charles BelovComment #2
Charles BelovComment #3
jhodgdonPutting back in the right component. This is about the CKEditor configuration, right?
Comment #4
Charles BelovYes. Thank you. So ckeditor configuration is not configuration then?
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous commented+1 for #3. 'ckeditor.module' is the component that situates the issue correctly. The 'configuration system' component is for issues on the entity configuration system, services configuration, etc.
This issue is caused by the
<ul>
tag #ckeditor-available-buttons that resizes to the minimum 26px as defined by .ckeditor-buttons (ckeditor.admin.css line 148). I am however not sure what a better value would be, or how this issue can be resolved properly.Comment #6
Wim LeersI cannot reproduce this. If it still exists, please create a short screencast to demonstrate it — thanks!
Comment #7
Charles BelovReopening with requested screencast. I originally filed this with Chrome Windows, but don't know how to do a screencast on Windows so am doing this on a Mac, where I am able to reproduce it.
Attempted steps:
1. Click to make Chrome the active app
2. Drag Tx icon to end of second row of icons (fail)
3. Drag Tx icon to within second row of icons (fail)
4. Drag Tx icon to first row of icons, then move to end of second row (success)
Comment #8
Wim LeersThanks, that's super helpful! I've now also successfully reproduced the problem!
I was able to narrow it down to a CSS problem (the
<ul>
is the drop area, but due to overflow it takes up more space than the element is actually large). Should be a simple CSS fix.Comment #9
Wim LeersDidn't mean to embed it in the IS.
Comment #10
PQ CreditAttribution: PQ commentedGiven that the height collapse is caused by the <li> elements floating, adding .clearfix should fix.
(My first D8) patch attached.
Comment #11
PQ CreditAttribution: PQ commentedComment #12
Charles BelovJust tested it on 8.0.0-beta15 with patch and it works.
Comment #13
maartendeblock CreditAttribution: maartendeblock at EntityOne commentedTested on the latest dev and works.
Comment #14
maartendeblock CreditAttribution: maartendeblock at EntityOne commentedComment #15
Wim LeersHah, so simple! I'm such a CSS noob for not having realized that myself in #8, where I did analyze it to the root cause of the problem :)
Thank you!
Comment #16
PQ CreditAttribution: PQ at D. Agency commentedNo Worries Wim. Your ground work made it loads easier to track down so thanks for that.
Comment #17
webchickYay, love fixes that turn out much simpler than you'd think. :)
Committed and pushed to 8.0.x. Thanks!