Make WordPress Core

Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#17136 closed task (blessed) (fixed)

Distraction-free writing mode

Reported by: azaozz's profile azaozz Owned by:
Milestone: 3.2 Priority: normal
Severity: normal Version:
Component: Editor Keywords: has-patch
Focuses: Cc:

Description

One of the main new features for 3.2. More details.

Attachments (8)

dfw-post-title-issue.png (14.1 KB) - added by aaroncampbell 14 years ago.
Title box issue
html.mode.diff (40.4 KB) - added by koopersmith 14 years ago.
html.mode.2.diff (40.5 KB) - added by koopersmith 14 years ago.
17136.diff (1.1 KB) - added by greuben 14 years ago.
17136.alt.diff (1.1 KB) - added by scribu 14 years ago.
adminpage
17136.2.diff (1.9 KB) - added by greuben 14 years ago.
press-this.diff (800 bytes) - added by greuben 14 years ago.
screenshot.png (37.4 KB) - added by greuben 14 years ago.

Download all attachments as: .zip

Change History (108)

#1 @azaozz
14 years ago

As discussed at the dev. chat, first run is a plugin so more people can have a look. http://plugins.svn.wordpress.org/tranquility/branches/wp-fullscreen-test-1.0.zip

#2 follow-up: @wpdavis
14 years ago

Loving it.

At first glance, the two things I notice is that some indication after the save button is pressed, and the help button doesn't seem to work.

#3 @azaozz
14 years ago

(In [17639]) Remove redundant IE restore selection calls for TinyMCE, see #17136

#4 in reply to: ↑ 2 @azaozz
14 years ago

Replying to wpdavis:

Yes, the Help button is only a placeholder for now. The save is still "in progress", i.e. not sure if we are going with just Save (saving a draft if the post is new/draft or updating it if it's published) or we will have the same buttons as in the postbox: Save Draft, Publish, Update, etc. Perhaps the right thing would be to have Save for drafts and Update for published posts.

#5 @linuxologos
14 years ago

  • Cc linuxologos@… added

#6 @ramoonus
14 years ago

  • Cc ramoonus@… added

#7 follow-up: @knutsp
14 years ago

  • Cc knut@… added

Amazing!

Please make it available from the HTML/plaintext editor, too.

And please issue a warning if you exit this editor without saving, and may be have a saved message after a successfull save. I lost a long text praising this new function, without ever getting any warning that my text was not saved as I exited it. I am sure I pressed the save button, but I could not see that it was actually not saved before after I exited it.

But apart from this, which is easily fixed, this is the way to go.

#8 in reply to: ↑ 7 @azaozz
14 years ago

Replying to knutsp:

Could you give some more details on how you've lost that "long text"? For example: did you close the fullscreen mode from the Close button (top/right in the top menubar)?

TinyMCE is set to raw copy/paste the content from the fullscreen to the "usual" editor on closing and on saving. Also the saving is done with XHR, so even if you close the browser after clicking on Save, the server will save the post.

#9 @knutsp
14 years ago

Yes, I used the top right close button (icon formed as an X) on the menu bar that appeared when I moved the pointer out of the text area.

#10 @aaroncampbell
14 years ago

  • Cc aaroncampbell added

#11 follow-up: @andrewryno
14 years ago

Since the close image doesn't have an anchor surrounding it, there isn't a cursor change when someone hovers over it. Very minor, but makes things looks less-clickable (at least to me). Should go to cursor: hover;.

Also, is there a reason why the editable area is so large? It's rendering at 19911px high in my test install. Might be by design, but not sure.

#12 @ocean90
14 years ago

  • Cc ocean90 added

#13 in reply to: ↑ 11 @azaozz
14 years ago

Replying to andrewryno:

This is only the (raw) first run, there will be many refinements in the next two weeks or so.

19911px is definitely not intended :). Are you using Chrome or Safari? They (WebKit) seem to report the wrong offsetHeight when TinyMCE is loading and also don't shrink the page height when content is deleted. Added a fix for that in the latest test version.

#15 @andrewryno
14 years ago

Using Chrome 10.0.648.205. 2.1 didn't initially fix the issue on my install. One post was even showing 29000px+ in height. It's applying the height to the iFrame but that's all I looked into. I just updated trunk (was a few revisions behind) and seems fixed now, though.

For the record I'm using trunk with the test content for theme reviewers. The problem only seemed to show up on posts that went beyond the bottom edge of the browser. Posts with only a line or two of content worked fine.

#16 follow-up: @chexee
14 years ago

There is a slight misalignment when the dotted lines fade away: http://cl.ly/2v1T3Y3V0f0K2m411a2p
The post text is inset around 5px from the post title text.

Also, when I type a lot of text, the box expands, but doesn't re-collapse when I remove text. If someone writes beyond the bottom of the window and induces a scrollbar, it doesn't disappear if they edit back down, which is a bit weird. Might make people think there is something at the bottom of the page they need to scroll to.

#17 in reply to: ↑ 16 @azaozz
14 years ago

Replying to chexee:

...when I type a lot of text, the box expands, but doesn't re-collapse when I remove text.

Unfortunately WebKit (Chrome, Safari) doesn't update any of the clientHeight, offsetHeight, scrollHeight etc. in document, documentElement or body when in contentEditable mode. Seems we will have to listen for the backspace and delete keys and force an autoresize at least in these cases (despite that I really hate adding more functions onkeyup). IE, FF and Opera seem ok.

@andrewryno for some reason WebKit was going wild when trying to get the iframe size before the CSS was applied completely. Tweaked the autoresize on init a bit, seems fixed now.

Last edited 14 years ago by azaozz (previous) (diff)

@aaroncampbell
14 years ago

Title box issue

#18 @aaroncampbell
14 years ago

There seems to be an issue where the label for the post title box gets layered over the actual post title. To reproduce:

  • Click to add new post
  • Go immediately into full screen mode
  • Add a title while in full screen mode
  • Click "back" to return to standard mode.

#19 @azaozz
14 years ago

(In [17695]) Distraction Free Writing mode, see #17136

#20 @azaozz
14 years ago

(In [17696]) Fix Opera event name and bump TinyMCE version string, see #17136

#21 @Otto42
14 years ago

Where did the fullscreen editor button go? I just updated a test site to trunk and it's missing the fullscreen editor button in TinyMCE. Checked the kitchen sink too, not there.

#22 @dd32
14 years ago

Where did the fullscreen editor button go?

Do you have nay TinyMCE related plugins installed? The Fullscreen button is the 2nd last on the top row.. right before the advanced button.. I havn't looked at the integration, but i'm assuming this has disabled the fullscreen and re-added it with another script, thus, any other plugins?

#23 follow-up: @Otto42
14 years ago

No, this is a default install on my local XAMPP, running twentyten. No plugins of any kind are activated on it. No fullscreen button appears at all now.

The 2nd to last button on the top row is the spell checker button. Then the kitchen sink button is immediately next to it.

Last edited 14 years ago by Otto42 (previous) (diff)

#24 @ocean90
14 years ago

After [17696] there are some notices in press this:

Backtrace from warning 'in_array() expects parameter 2 to be array, string given' at /wp-admin/includes/post.php 1697:
/wp-admin/includes/post.php 1697 calling in_array()
calling wp_preload_dialogs()
/wp-includes/plugin.php 405 calling call_user_func_array()
/wp-admin/press-this.php 638 calling do_action()

Backtrace from warning 'in_array() expects parameter 2 to be array, string given' at /wp-admin/includes/post.php 1702:
/wp-admin/includes/post.php 1702 calling in_array()
calling wp_preload_dialogs()
//wp-includes/plugin.php 405 calling call_user_func_array()
//wp-admin/press-this.php 638 calling do_action()

Backtrace from warning 'in_array() expects parameter 2 to be array, string given' at //wp-admin/includes/post.php 1710:
/wp-admin/includes/post.php 1710 calling in_array()
calling wp_preload_dialogs()
/wp-includes/plugin.php 405 calling call_user_func_array()
/wp-admin/press-this.php 638 calling do_action()

#25 @azaozz
14 years ago

(In [17697]) Fix padding in DFW mode, add the new wpfullscreen plugin in wp-tinymce.js.gz, fix notices in press-this see #17136

#26 in reply to: ↑ 23 @azaozz
14 years ago

Replying to Otto42:

Sorry, I should have mentioned that it was only available when SCRIPT_DEBUG was on. Added it to the gzipped TinyMCE so it works without SCRIPT_DEBUG now.

Yes, it replaces the default TinyMCE fullscreen plugin and uses the same button.

#27 @johnjamesjacoby
14 years ago

Some feedback after giving this a go:

  • The fade animation feels just a bit too long. Right now it has a zen like speed, which doesn't match the rest of the admin area's snappy race-car speed. (It's slow enough I wondered if it was broken for a split second.)
  • I think the ESC key should exit distraction free writing, as a 'panic mode' way to save draft + exit.
  • When entering/exiting, any way to remember the focus and position of the carrot?
  • Replace the word "Back" with "Leave." My brain thought that I entered dfw, so I wanted to leave when I was done.
  • Does clicking the "Back" link save my writing, or do I lose it all? Maybe there should be two links? "Save & Leave" and "Leave Without Saving" ?
  • The "More" tag styling background is still white and needs explicit styling for dfw to match.

#28 follow-up: @greuben
14 years ago

The borders and toolbar fade when typing and do not appear until I move my mouse.

http://i55.tinypic.com/11jvint.jpg

#29 in reply to: ↑ 28 @chexee
14 years ago

Replying to greuben:

The borders and toolbar fade when typing and do not appear until I move my mouse.

http://i55.tinypic.com/11jvint.jpg

I believe that is what is supposed to happen. Distractions (ie the Toolbar) fade when not in use to allow the user to focus on writing and only reappear when needed (ie when they move their mouse).

#30 follow-up: @greuben
14 years ago

@chexee: Maybe but the borders should not disappear.

#31 in reply to: ↑ 30 @chexee
14 years ago

Replying to greuben:

@chexee: Maybe but the borders should not disappear.

The borders disappearing are also intentional. There's been a little discussion on this. I like the borders disappearing, as it gives me the illusion that I'm maybe writing on a blank sheet of paper and keeps focus solely on the words.

Someone mentioned that its a little intimidating to have the blank page. Any other reasons why anyone thinks the borders shouldn't fade?

#32 @greuben
14 years ago

Any other reasons why anyone thinks the borders shouldn't fade?

The borders fade while I'm writing(not onfocus) and that is somewhat distracting.

#33 @nacin
14 years ago

The point is they're no longer distracting when gone. This is intended behavior.

Last edited 14 years ago by nacin (previous) (diff)

#34 @chexee
14 years ago

Replying to greuben:

Any other reasons why anyone thinks the borders shouldn't fade?

The borders fade while I'm writing(not onfocus) and that is somewhat distracting.

From clicking into the post box, I can type about two words before the borders fade out. I think thats a pretty good benchmark. Doesn't stick around for too long and fade in the middle of sentences or paragraphs and doesn't fade out fast enough that I can't finish hitting a button before it disappears.

Last edited 14 years ago by chexee (previous) (diff)

#35 @aaroncampbell
14 years ago

+1 on changing "back" to "leave". I think that "back" already has a meaning in a web browser, and closing DFW isn't it.

As for the borders fading, it was a little distracting and confusing the first time because I switched tabs right after loading DFW and focusing on title (before the fade) and came back to an all-white page. However, this is only an issue if you don't watch the fade AND you're creating a new post AND you're focused on the title box (otherwise you see the "Enter title here" label).

The issue I had was that if you are focused in the content box ctrl+tab doesn't switch me to the next tab in FF like it should (nothing happens) and ctrl+shift+tab doesn't take me to the previous tab it moves focus to the title box. This seems to work fine in Chrome. I'll try to test more when I get to another computer, but I can repeat the issue on several trunk installs using Firefox 4.0 on Ubuntu.

#36 @johnjamesjacoby
14 years ago

The "decisions over options" mantra is engraved in my soul and all that, but the toolbox area could have a checkbox or button to "stick" it open, so it doesn't fade away.

Also, having the links and buttons all the way in the upper left and right corners is a bit intimidating. We're talking milliseconds and hundreds of pixels here so it isn't profound, but it takes a more of a mental commitment to move the mouse all the way up to the far edge rather than straight up to the focal area of the pseudo-toolbar.

Also thinking that having the word-count be visible in a really light grey might be a helpful reminder about the length of the post. Since the idea with dfw is to let the words flow for a long enough period of time to necessitate complete concentration on the task, knowing the result without needing to grab the mouse and wiggle it around for the toolbar to fade in might be an experience worth trying out.

#37 @chexee
14 years ago

+1 to moving the Links and buttons closed to the wrapper area. Would probably require a slightly taller toolbar, though :[

I brought up the word count thing before as a possible incentive for writing more. dkoopersmith reminded me that DFW should be focused on content quality, rather than content quantity. I don't think most bloggers are blogging for assignments.

Also would say I'm against having a sticky checkbox for keeping the toolbox there. Decisions not options and a focus on the Distraction Free part of DFW :]. Less is more here, I think.

#38 @azaozz
14 years ago

  • Back button, we can probably have "Close" there or something like "Back to standard mode".
  • Don't think the buttons are too far away, not sure how it would look like if moved.
  • We can add a mouseover on the top bar that would keep it open while the cursor is there (think @koopersmith has already added that in the next patch).

Perhaps we can keep the ticket for patches/bug reports and discuss it at dev. updates.

#39 follow-up: @nacin
14 years ago

I suggested to Koop that the text/links flushed left and right shouldn't be against the edges of the screen, rather, they should be flush 150px or so to the left or right of the content area. So still outside the content area, but not all the way against the screen. This is useful for larger screens (even just a decent laptop resolution) where the top left and right corners are really far away.

If we wanted to move the word count, I could see it being again in this gutter region, gray text, on the bottom to the right. Might help free up the clutter of a lot of text along the top bar. (It should fade out with everything else.)

Finally, one issue is that once you've scrolled down so the content area spans the height of the viewport, you can't actually get the toolbar to appear without moving your mouse off to the left or right, requiring you to move the mouse up, then to the left off the content area, then to the right again (say to click the link button). Koop said he was going to work on a patch.

#40 in reply to: ↑ 39 @azaozz
14 years ago

Replying to nacin:

...the text/links flushed left and right shouldn't be against the edges of the screen, rather, they should be flush 150px or so to the left or right of the content area...

Sounds (and looks) good.

...once you've scrolled down so the content area spans the height of the viewport, you can't actually get the toolbar to appear without moving your mouse off to the left or right, requiring you to move the mouse up, then to the left off the content area, then to the right again (say to click the link button)...

I see this as a feature, not bug. It would be quite distracting to show/hide the top bar all the time while editing as the mouse is moved to select, copy, paste text, etc.

#41 @azaozz
14 years ago

(In [17702]) DFW: remove unneeded JS global, fix screen flash in WebKit, props koopersmith, see #17136

#42 @azaozz
14 years ago

(In [17703]) Don't hide the top bar when the cursor is over it, see #17136

#43 @markjaquith
14 years ago

The mouse behavior is odd. You have to move the mouse outside of the invisible content area and waggle it around. Mouse movement anywhere should trigger the UI fade in.

#44 @aaroncampbell
14 years ago

Replying to aaroncampbell:

The issue I had was that if you are focused in the content box ctrl+tab doesn't switch me to the next tab in FF like it should (nothing happens) and ctrl+shift+tab doesn't take me to the previous tab it moves focus to the title box. This seems to work fine in Chrome. I'll try to test more when I get to another computer, but I can repeat the issue on several trunk installs using Firefox 4.0 on Ubuntu.

This wasn't DFW specific, but rather and issue affecting tinyMCE #17261

Version 0, edited 14 years ago by aaroncampbell (next)

#45 @markjaquith
14 years ago

After saving in DFW, if you exit and save in normal mode, you get punted out to the Edit Screen.

#46 @markjaquith
14 years ago

Can we make the fade out transition slower (1.5x) and the fade in transition quicker (x/2) ?

#47 @ctsttom
14 years ago

Just tried out the version 1.0 and 2.1 plugins, the style of the 1.0 plugin is better, more wordpress-esk I don't think the dashed lines and square corners really work well.

#48 @ctsttom
14 years ago

  • Cc ctsttom added

#49 @koopersmith
14 years ago

  • Keywords has-patch added

Patch posted for HTML mode. It is decidedly non-trivial.

Known issues:

  • Icons will not appear when loading from HTML mode if the visual editor has never been loaded.
    • This is because the icon CSS is loaded when TinyMCE is first initialized. I'd propose shifting in some of the styles from ui.css into wp-admin.css (note that some already reside in colors.css), but did not include this in the patch.
  • The toolbar fading is acting funky.
    • I'll get to that next.

#50 @koopersmith
14 years ago

Also, I've tested the patch in Chrome, FF, and IE8. Note that there is a jQuery bug in IE8 that predates this patch.

#51 @koopersmith
14 years ago

Latest version also removes webkit glow and gecko resizing on the HTML textarea.

#52 @azaozz
14 years ago

In [17785]:

HTML mode for Distraction Free Writing, props koopersmith, see #17136

#53 follow-up: @azaozz
14 years ago

In [17786]:

Fix action handling code, see #17136

#54 in reply to: ↑ 53 ; follow-up: @westi
14 years ago

Replying to azaozz:

In [17786]:

Fix action handling code, see #17136

What was broken with this code which required this change.

We are going from an efficient to use array to adding a parsing step for seemingly no real benefit?

#55 in reply to: ↑ 54 @azaozz
14 years ago

Replying to westi:

Sorry, should have explained it better. [17785] adds another action to wp_tiny_mce() and standardizes the previously added action: before_wp_tiny_mce and after_wp_tiny_mce. Both get the $initArray as arg. They make it very easy to add scripts and other elements just before or after the code for TinyMCE is outputted (both are used in core).

The change in [17786] is needed as the list of used plugins in $initArray is (already) a comma delimited string and we need to check whether some plugins are present there and output other components for them. Using preg_split() and then inArray() there seemed most straightforward (it's a short string). We can instead add the $plugins as second arg. to these actions or even use strpos() if needed.

#56 follow-up: @markmcwilliams
14 years ago

When using the Visual Editor, and trying to toggle between the DFW screen, it doesn't work in IE8. Visiting it however, from the HTML Editor, it does. Feels like it doesn't exist, and it only happened after the HTML DFW screen went in (although that's pretty cool too!)

#57 @lioman
14 years ago

  • Severity changed from normal to trivial

I downloaded Version 2.1 and noticed that the Versionnumber isn't changed.

#58 @dd32
14 years ago

  • Severity changed from trivial to normal

lioman: the plugin is now out of date, All current development past the initial "ideas" plugin has been in WordPress trunk (What will become WordPress 3.2)

#59 @swissspidy
14 years ago

  • Cc hello@… added

#60 in reply to: ↑ 56 ; follow-ups: @azaozz
14 years ago

Replying to markmcwilliams:

When using the Visual Editor, and trying to toggle between the DFW screen, it doesn't work in IE8.

I've been testing in IE8 all the time and it works as expected here. Some more info about exactly what happens would be helpful.

@lioman what @dd32 said, also the plugin should be uninstalled/deleted when running the trunk (latest alpha) version of WordPress as it would interfere with it.

#61 in reply to: ↑ 60 @markmcwilliams
14 years ago

Replying to azaozz:

Replying to markmcwilliams:

When using the Visual Editor, and trying to toggle between the DFW screen, it doesn't work in IE8.

I've been testing in IE8 all the time and it works as expected here. Some more info about exactly what happens would be helpful.

I recorded http://www.screenr.com/EX9 to see if it might help, but it's got no sound!

It's a basic install, and I'm using Twenty Ten, with nothing more than Akismet activated. As can be seen within the video, on the Visual Editor, I get no responce when I click the fullscreen mode button; but I do within the HTML Editor which brings up with DFW screen. But to add, you can also see trying to toggle between the two doesn't want to do so ...

But if you've been using IE8 and testing it there, then it sounds like something is 'broken' at my end?

#62 @azaozz
14 years ago

In [17837]:

DFW: import editor-style.css, fine-tune transition times, add width resizing setting, some cleanup, see #17136

#63 @azaozz
14 years ago

In [17838]:

DFW: change width resizing to use hotkeys only: Alt (Win, Linux) or Ctrl (Mac) 0/reset, +/wider, -/narrower, see #17136

#64 @azaozz
14 years ago

In [17840]:

Close >> Exit fullscreen, see #17136

#65 follow-up: @azaozz
14 years ago

In [17852]:

DFW: add Blockquote button, enable After the Deadline button if plugin is installed, set button state, see #17136

#66 in reply to: ↑ 60 @markmcwilliams
14 years ago

Replying to azaozz:

Replying to markmcwilliams:

When using the Visual Editor, and trying to toggle between the DFW screen, it doesn't work in IE8.

I've been testing in IE8 all the time and it works as expected here. Some more info about exactly what happens would be helpful.

Whatever it was has ironed itself out! :)

#67 in reply to: ↑ 65 ; follow-up: @westi
14 years ago

Replying to azaozz:

In [17852]:

DFW: add Blockquote button, enable After the Deadline button if plugin is installed, set button state, see #17136

We shouldn't have code in core to Support a plugin. We should have a hook for the plugin to use - and any other plugin that wishes to add a button here.

#68 @azaozz
14 years ago

In [17856]:

DFW: add tagline, move the Word count under the editor, see #17136

#69 in reply to: ↑ 67 @azaozz
14 years ago

Replying to westi:

Agreed, will think of a way to do that properly after 3.2 beta is out.

#70 follow-up: @Denis-de-Bernardy
14 years ago

I've been trying out the new distraction-free writing mode on MacOS/Safari. Is it just me, or the animations are a bit slow? We might benefit from making it a bit snappier when it loads.

#71 in reply to: ↑ 70 @markjaquith
14 years ago

Replying to Denis-de-Bernardy:

I've been trying out the new distraction-free writing mode on MacOS/Safari. Is it just me, or the animations are a bit slow? We might benefit from making it a bit snappier when it loads.

I agree. I think we could easily cut them in half. I get the point of showing an animation, but it shouldn't be so sluggish.

#72 @azaozz
14 years ago

In [17880]:

Improve code for DFW buttons, fix colors in some rare TinyMCE popups, see #17136

#73 follow-up: @jane
14 years ago

  • Resolution set to fixed
  • Status changed from new to closed

This feature is in. Closing ticket, any bugs should get new tickets.

#74 in reply to: ↑ 73 @Denis-de-Bernardy
14 years ago

Replying to jane:

This feature is in. Closing ticket, any bugs should get new tickets.

One was raised within this ticket just today further up: animations are bogging the whole thing down. Why close the ticket before fixing it?

#75 @azaozz
14 years ago

In [17913]:

DFW: scroll to top when opening so the user is not disoriented, see #17136

#76 @azaozz
14 years ago

In [17936]:

Fix autosave and word count for DFW HTML editor, always update word count on autosave, see #17136

#77 @nacin
14 years ago

<?php _e('Word count:'); ?> <span class="word-count">0</span>

should probably be, for maximum i18n flexibility:

<?php printf( __( 'Word count: %s' ), '<span class="word-count">0</span>' );

#78 @azaozz
14 years ago

In [17940]:

Maximum i18n flexibility for word count, props nacin, see #17136

#79 @scribu
14 years ago

The fullscreen button also shows up on the comment editing screen.

Related: #16695

#80 @azaozz
14 years ago

In [17947]:

Use the "media" admin menu icon for the add media button in DFW, move the tagline, see #17136

#81 @azaozz
14 years ago

In [17949]:

Fix width shortcuts in DFW, see #17136

#82 @scribu
14 years ago

  • Keywords needs-patch added; has-patch removed

#83 @scribu
14 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

@greuben
14 years ago

#84 @greuben
14 years ago

  • Keywords has-patch added; needs-patch removed

#85 follow-up: @scribu
14 years ago

Heh, didn't thinkg it would be that easy. :)

Wouldn't 'post' == pagenow make more sense?

#86 @scribu
14 years ago

There's still the issue of wp-fullscreen.js being loaded for that screen, but I guess we can live with that.

#87 in reply to: ↑ 85 @greuben
14 years ago

Replying to scribu:

Heh, didn't thinkg it would be that easy. :)

Wouldn't 'post' == pagenow make more sense?

No, for pages it is 'page' and for custom post types it is different

@scribu
14 years ago

adminpage

#88 follow-up: @scribu
14 years ago

Right. I was thinking of adminpage.

See 17136.alt.diff.

#89 in reply to: ↑ 88 @greuben
14 years ago

Replying to scribu:

Right. I was thinking of adminpage.

See 17136.alt.diff.

Wouldn't this restrict fullscreen to post.php page only. Fullscreen can be used somewhere else like front-end post editor(example)

#90 @scribu
14 years ago

Actually, no, it couldn't be used anywhere else but on the post editing screen. If it could, we wouldn't be having this discussion. :)

In a hypothetical front-end post editor - assuming you could get the fullscreen editor to work in this context - you could just re-create the adminpage variable.

@greuben
14 years ago

#91 @greuben
14 years ago

There's still the issue of wp-fullscreen.js being loaded for that screen, but I guess we can live with that.

17136.2.diff

@greuben
14 years ago

#92 follow-up: @greuben
14 years ago

press-this.diff removes fullscreen button for press-this

#93 in reply to: ↑ 92 ; follow-up: @azaozz
14 years ago

Replying to greuben:

press-this.diff removes fullscreen button for press-this

Why do you want to remove it? It's the default fullscreen plugin for TinyMCE and is working pretty nice in Press This.

#94 @azaozz
14 years ago

In [17966]:

Don't show the Fullscreen button on the comment edit page, see #17136

@greuben
14 years ago

#95 in reply to: ↑ 93 @greuben
14 years ago

Replying to azaozz:

Replying to greuben:

press-this.diff removes fullscreen button for press-this

Why do you want to remove it? It's the default fullscreen plugin for TinyMCE and is working pretty nice in Press This.

I thought the fullscreen was replaced with DFW.

http://core.trac.wordpress.org/raw-attachment/ticket/17136/screenshot.png

#96 @azaozz
14 years ago

In [17970]:

FIx the position of Enter title here, see #17136

#97 @azaozz
14 years ago

In [17974]:

When viewing Help in DFW, show only the shortcuts tab, see #17136

#98 @dougwrites
14 years ago

  • Cc heymrpro@… added

Tiniest of TinyMCE issues: can we add a hyphen to "Distraction free writing" in the shortcuts tab box from [17974] (start of 2nd paragraph)?

#99 @ryan
14 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

Please report further issues on new tickets. Marking this feature ticket as resolved.

#100 @ctsttom
13 years ago

  • Cc ctsttom removed
Note: See TracTickets for help on using tickets.