Hi!

One of the issues we have been dealing with etherpad in sandstorm is that the font size cannot be made bigger with the usual ctrl + because everything grows and not just the pad buttons. Currently there is no plugin to configure the font size, and i just use to edit manually the etherpad css to fix this (there is one to configure text family, font size, etc but if you write something new it's back to the old size).

ether#2671

If it's not possible, what would be the options to get this done? there are a couple of coworkers complaining they will get blind ;)

Hi,

It would be very helpful to have the option to count words in the document.

The plugin ep_countable appears to provide this functionality (I did not try it, though).

Thanks.

When printing a Etherpad using its print button text only appears on the first page of the output (I used a PDF printer). Author colors for the lines do appear in the margins of subsequent pages so there is "something".

This bug happens in Sandstorm-hosted Etherpads. I hope this is the right repo to report bugs with that, if not, please accept my excuses.

Steps to reproduce:

• Create a new Sandstorm Etherpad grain

• Change the authorship sidebar to not appear for this grain

• Reload the page

Expected results:

• Authorship sidebar continues to not appear for this grain

Actual results:

• That setting is reset to its default of "Yes", show the authorship sidebar

Video of steps to reproduce:

My assumption when I would share a document would be that people would not see the different colors / history of the document. If I were to use this in a professional capacity and share a document with a client where I had set my view to not see the colors, but they had not, and I shared a multi-colored document, it would look unprofessional. I would also not necessarily expect that a document I didn't see colors on would have highlighted text when shared with someone else.

Another fix strategy I could imagine would be to have the default collaboration uncolored and to "opt-in" or "turn on" the feature.

Line numbers are useful to refer to a specific zone in the document while collaboratively discussing it, but the ep_author_neat plugin replaces them.

Consider adding something like clkao/ep_author_neat#18 to restore them, as well as an option for enabling/disabling them (real "Show line numbers")?

• Make an Etherpad
• Make sure there's some text
• Make a read-only share link
• Open in incognito tab
• Select text
• Bold the text

It will turn bold. However if you refresh the page, the formatting will reset. So, it doesn't save.

Slight vertical misalignment of authorship color (from the plugin) by approximately 1 line.

The list of fonts shown in the "font families" and "font type" setting (in settings) are different.
This makes it very hard to set a font consistently for the document. For example, if the font is changed using "font families", there may be no equivalent for the default font set in "font type" resulting in inconsistent fonts on further editing.

Steps to reproduce:

• Create a new Etherpad grain, e.g. on demo.sandstorm.io in an incognito window.

• Press Ctrl-B on one's keyboard (or persumably Option-B on a mac?).

• Type some text.

Expected behavior:

• The new text is written-out as bold.

Actual behavior:

• The new text isn't bold, but instead is in the default style.

Implementation notes:

• Per ether#447 , the ep_sticky_attributes plugin should enable this behavior. However, per the default grain text, that plugin is enabled in Etherpad on Sandstorm. Therefore, I'm not quite sure what to suggest here except possibly tracing how keyboard events are handled in the case of Ctrl-B.

Using version 1.5.7 from 2015 Aug 16, which is in in the app market.

When creating a new grain, the plugin ep_markdown seems to be included according to the initial pad content:

This version of Etherpad includes the following plugins: ep_align ep_author_neat ep_comments_page ep_font_color ep_font_family ep_font_size ep_headings2 ep_markdown ep_page_view ep_print ep_spellcheck ep_sticky_attributes ep_subscript_and_superscriptd

However, there seems to be no way to use it.

There should be a "view markdown" option in the settings.

There should be a "markdown export" option.

Hi, I'm trying Etherpad on Sandstorm. It's working very nicely.

Are you planning on also supporting Etherpad plugins?

The file exported contains an odd LaTeX-like version of the initial Etherpad text for a newly-created document:

Welcome to Etherpad!

This pad text is synchronized as you type, so that everyone viewing this page sees the same text. This allows you to \
collaborate seamlessly on documents!

Get involved with Etherpad at \url{http://etherpad.org}

This version of Etherpad includes the following plugins: ep\_align ep\_author\_neat ep\_comments\_page ep\_font\_colo\
r ep\_font\_family ep\_font\_size ep\_headings2 ep\_markdown ep\_page\_view ep\_print ep\_spellcheck ep\_sticky\_attr\
ibutes ep\_subscript\_and\_superscript

For what it's worth, the documents which I was attempting to export all contained basic, minimal elements of Markdown syntax, e.g. using square-brackets followed by parentheses for links, and # symbols for headings.

While I as a user already have the ability to share the link with someone else, I would like the ability to click a button to share it with another user. This button would send them an email with the link for them to view it / edit it.

After checking the boxes for "chat always on screen" and "show chat and users" and switching between different grains, closing the etherpad grain, and opening it again, the settigns seem lost.

It's not actually included anymore.

When hovering over a commented-on range, Etherpad shows a popup box with the comment. Under certain circumstances, this will appear directly under the mouse, which means the mouse is no longer hovering over the commented range, so Etherpad hides the popup box. But then the mouse is hovering over a commented-on range again, so Etherpad shows the box.

This makes it very hard to actually read the comment thread. An example of a problematic layout for a comment can be found in the screenshots below. The following two frames alternate as quickly as the browser can render them:

The Timeslider button doesn't do anything, so I can't access revisions.
This is a must have functionality for collaboration...

edit: This works in alpha, not in demo / oasis.
Doesn't work on my local and I have 0.101, same as alpha, and Etherpad is the same version (v2015.06.18 (1.5.6+)).

@paulproteus commented in a PR that you commented that a document probably shouldn't contain sample data, so it is ready to use at the outset. This probably holds true for Etherpad as well. :)

My first step to opening a new text file shouldn't be deleting the stuff that's in it.

As a user, I would like to know what version of Etherpad I am using.

The clear authorship colors could use a more intuitive icon.

User icon didn't display at all until the grain was refreshed. I haven't been able to reproduce this issue but I'll file it here so additional details can be added if it happens again.

Very-old etherpads can't be opened with the latest version.

See screenshot Jade will provide.

Thank you for all of your hard work. Would it be possible for you to include syntax highlighting in Etherpad?
It would be VERY useful.

When a comment is made on a range of text toward the end of a pad with scroll height larger than the window height, it's basically impossible to read/interact with the comment thread, because the comment box always goes below the highlighted section, so in this case it extends the length of the document offscreen. But if you scroll down to try to read the comment, you likely stop hovering over the highlighted section, and the comment thread disappears, which causes the height to return to its previous value. It becomes very hard to actually read comments.

Possible solutions, in order of most desirable to least desirable, include:

• make clicking on a region with comments toggle showing the comment thread, so that you don't have to be very precise with a mouse ever
• don't immediately hide the comment thread when hover ends, and keep the comment thread visible if hovering over the comment thread box
• show the comment box somewhere else that doesn't affect scroll height (some threads may be longer than the document, though)

May I suggest the following plugins for the next build:

Tables:
https://www.npmjs.com/package/ep_tables2

Images (copied from clipboard)
https://github.com/JohnMcLear/ep_copy_paste_images

These would make etherpad on Sandstorm even more useful as a general collaborative scratchpad.

To reproduce:

• User A opens a grain in browser tab 1.
• User A leaves a comment.
• User A keeps browser tab 1 open.
• User B replies to the comment.

I would expect that when user A hovers over their comment, they should see their comment and user B's reply.

Instead, they see just their own comment.

Additionally, if user B makes a comment elsewhere in the pad, user A will see that range highlighted, but when user A hovers over that range, they see the first thread, rather than the new comment.

This plugin would be really good to have available:

https://github.com/JohnMcLear/ep_tasklist

At the moment, there's no app in sandstorm that I've found which allows collaborative task lists,
etherpad with the tasklist plugin would fill the void nicely!

Can Abiword be added into the Etherpad package to allow DOC/DOCX import/export?

Steps to reproduce:

• Create a new Etherpad grain

• Clear all text within it

• Copy this single line of text, with a space at the end of it, to the clipboard:

But maybe the rain isn't really to blame. So I'll remove the cause, but not the symptom.

• Paste it a few times

Expected behavior:

• Every line (except possibly the last line) in the paragraph takes up the full width of the page.

Actual behavior:

• Etherpad appears to introduce some line wrapping, sometimes mid-word.

Screenshot:

Hello,

I'm using the latest sandstorm version and since today all of my etherpad grains crash using the latest firefox(57.0) on OSX (El Capitan, 10.11.6). (But for the first days it went fine with it). Then:

An error occurred while loading the pad
ReferenceError: require is not defined in https://.................sandcats.io/p/main (line 858)

//

The first time I got another error, something like "type error: c is null..." But now I just get the above for every single existing document and for any new ones I try to create.

– In Chromium it just works fine.

Any idea?

P.S: I'm not sure, if "crash" is the right word, the App opens, but the View is completey crashed (CSS not working) and no content or way to edit...

In order to show someone a document I have collaborated with someone on, I would like the ability to share the document in a "read-only" status, where they would not have permission to edit it, but only view it.

Right now, the activity event includes the path, thread path, and title, but no body.

If it included the comment, we could include the body of the comment in email notifications.

http://blog.etherpad.org/2018/04/07/important-release-1-6-4/

"""TLDR; Site admins should Update ASAP to 1.6.4 due to several security enhancements.

Today we released Etherpad 1.6.4.

This release fixes several security vulnerabilities in recent versions:

One is an arbitrary code execution vulnerability in version 1.6.3.
Another is an arbitrary code execution vulnerability which is present in all versions from 1.5.0 on, but only exploitable on sites that store pads in DirtyDB, CouchDB, MongoDB, or RethinkDB.
A third allows attackers to export any pad without knowing its name (as normally required) in all versions from 1.5.0 on."""

Steps to reproduce:

• Visit https://demo.sandstorm.io/ and make an Etherpad
• Type hello into it
• Open a new browser window (with the same browser) and open the same grain URL

Expected results:

• You can type in either window and see the text in both.

Actual results:

• One window marks itself as disconnected.

Steps to reproduce:

• Create a new Etherpad document with today's release of Etherpad

• Leave a comment

• Click on any background (non-text) area of the comments box

Expected results:

• nothing

Actual results:

• Comments box, about 0.2 seconds later, has its background blink

Image attached. Ignore the black rectangle where the mouse should be.

Comments are only displayed in the gutter if your screen is particularly wide. The form to allow you to write a reply is only visible in the gutter.

If your browser window is not fullscreened, you may never discover that you can actually reply to comments!

Reproduction:

• User 1 creates new etherpad grain
• User 1 creates new sharing link via share access button
• User 2 (who is already logged in) opens that link
• User 1 types into the window
• User 2 sees that text attributed to "Unknown Author". I would expect it to show User 1's display name.
• User 2 types into the window
• User 1 sees that text attributed to "Unknown Author". I would expect it to show User 2's display name.

If User 1 refreshes the page, the apparent authorship information is corrected for both users. (I didn't test what happens if User 2 does likewise; I imagine it would probably also fix the attribution labels.)

In the screenshots below, Alice Dev Admin is User 1 and Dave Dev User is User 2.

Apparently hitting backspace refreshes the grain when you're a read-only viewer on an Etherpad. This was confusing when I was invited to an Etherpad document and I didn't realize that @kentonv only granted me read-only permissions. So as I was trying to edit, highlighting text and hitting backspace, I just kept refreshing the grain. Confused, I tried again, and keep refreshing it.

We should maybe (1) make typical edit action keys (like backspace) not trigger a refresh, and (2) indicate to the user what mode they're in in such a scenario.

Steps to reproduce:

• Start by using Safari on a Mac.

• Open a new Etherpad document, e.g. using demo.sandstorm.io.

• Make the document longer than one screen tall by e.g. copying and pasting the contents until you would need to scroll to see the entire document.

• Click inside the text of the document.

• Press and hold the keyboard down arrow key in an attempt to make the document scroll down.

Expected behavior:

• The viewable area of the text moves down. (This happens on Chromium on Debian for me.)

Actual behavior:

• No change in the viewable area of the text.

Notes:

• This was reported by an avid Sandstorm user to support@. I verified the issue by having @jadeqwang test out the above steps-to-reproduce on her Mac.

When one user changes colours of some text and then another user edits that text,
changing colours then fails to update the colour of the text that the second user changed.