quilljs / quill Goto Github PK

1. Tab into the editor.
2. Press shift+tab to tab back to the previous element.

Note that a tab is inserted instead of the focus being set on the previous element.

To reproduce:

• Enter two lines of text.
• Set each to monospace.
• Highlight all.
• Set font to monospace.

Expected behavior: Fonts stay monospaced.
Actual behavior: The first line reverts to default Sans Serif, second line stays monospaced.

1. Type link.
2. Select 'link'.
3. Hyperlink it.
4. Append 's' to the hyperlinked 'link'.

Expected: 'links', all hyperlinked.
Actual: 'link' is hyperlinked, 's' is not.

All other formatting types have the behavior that appending maintains the formatting; I don't think that links should be any different, but I could be overlooking a good reason for this?

1. type 'a'.
2. Move cursor to index 0.
3. Move cursor to index 1

Expected: Cursor is at index 1.
Actual: Cursor is at index 0
Version: IE9.

If you type multiple lines, then this is not an issue. Added a test to cursor.rb (see commit 2c69070) to prevent regression.

If user specifies http, leave as http. We force a protocol to prevent xss. Perhaps a better algorithm is keep either http or https, otherwise, strip the protocol?

This seems to only apply when modifying a mid-string char; i.e., the 'b' in 'abc'.

1. Highlight 'b'
2. Select 'Serif'.
3. Select 'San Serif'.

The dropdown should read 'San Serif', but still reads 'Serif'. editor.getOps() indicates that the delta has been updated correctly though.

The same issue occurs with all other dropdowns when switching back to a default style; for example, when switching back to the "Normal" size or the "White" background color.

1. "abc"
2. Apply formatting to "b"
3. Highlight "b" if not already
4. Hit the delete.

Expected: The cursor is at index 1, between "a" and "c"
Actual: The cursor is at index 2, after "ac"

Note that you must hit delete; backspace works fine.
Works fine in Chrome.

Ubuntu 12.04 LTS / Firefox 19.0.2
"debugger" break-point in fuzzer.rb prior to fuzzer logic.
attr_accessor :cursor_pos in selenium_adapter.rb

To reproduce:

1. Run: ruby fuzzer.rb firefox file://"your fuzzer.html path here"
2. Click the editor in the firefox window, and then click back into your terminal.
3. In rdb: set autoeval
4. In rdb: adapter.type_text "abcdef"
5. In rdb: adapter.doc_length
6. In rdb: adapter.cursor_pos
7. In rdb: adapter.move_cursor 0
8. In rdb: adapter.type_text "ZZZ"

Expected behavior at step x:
5. doc_length should be 6
6. cursor_pos should be 6
8. "ZZZabcdef"

Actual behavior at step x:
5. doc_length is 0
6. cursor_pos is 0
7. "aZZZbcdef"

Adding newlines at the end from user input should scroll the editor to keep the cursor in view

1. "abc\ndef"
2. Move cursor to index 2, before the c
3. Shifth + right arrow highlight "c\n"

Expected: "c\n" is highligted
Actual: "c\nde" is highlighted.

Internet Explorer 9, 10.

Currently set at 100% min height thus padding guarantees scrollbar

1. Type abc
2. Select 'ab'
3. Set to bold
4. Type ab

Expected: ab is bold, c is not
Acceptable: abc are not bold
Actual: a is bold, bc are not

Occurs in Firefox, not Chrome, who knows about IE

If I paste bullet points from outlook for example, pasting does nothing, the result is like pasting blank characters.

Instead of rendering Scribe inside it's iframe, IE instead displays a page reading "Internet Explorer cannot display the webpage."

Occurs in IE 9 & 10.

Ubuntu 12.04 LTS / Firefox 19.0.2
"debugger" break-point in fuzzer.rb prior to fuzzer logic.

To reproduce:

1. Run: ruby fuzzer.rb firefox file://"your fuzzer.html path here"
2. Click back into your terminal once firefox is open
3. In rdb: set autoeval
4. In rdb: (adapter.type_text "abcdef").class

Expected behavior: Fixnum (value: 6)
Actual behavior: String (value: "")

To check values, simply remove ".class" from step 4

1. Type 'a'
2. Hit enter

The error: "IndexSizeError: Index or size is negative or greater than the allowed amount" is raised.

If you move the cursor around after hitting enter, it does seem that the newline was actually added. However, if you instead type any further characters they won't appear.

I think a necessary precondition is that we start with the empty document. I can't reproduce this in demo/index.html, but it does occur in demo/pretty.html and also in fuzzer.html.

Ubuntu 12.04 LTS / Firefox 19.0.2
"debugger" break-point in fuzzer.rb prior to fuzzer logic.

To reproduce:

1. Run: ruby fuzzer.rb firefox file://"your fuzzer.html path here"
2. Alt-Tab back into terminal
3. In rdb: set autoeval
4. In rdb: adapter.type_text "abcdef"

Expected behavior: "abcdef" in the editor
Actual behavior: nothing in the editor

Additional notes:
In the Firefox window, the address bar has initial focus.
At step 2, if you CLICK back into the terminal instead of using alt-tab the behavior is as expected: "abcdef" prints in the editor. HOWEVER, Firefox steals focus the first time adapter.type_text is called, requiring you to alt-tab/click back into terminal.
At step 2, if you click the editor, and then alt-tab/click into the terminal the behavior is as expected: "abcdef" prints in the editor

I experienced this when pasting the same bullet points in a previous bug. But this time I only selected a subset of the line of text so as not to include any line delimiters and this caused the resulting paste to be broken into multiple lines.

After about 35 characters the title field will drop to the next line and disappear from the view.

User must explicitly click in for cursor to be detected

1. Select text
2. Change color to red
3. Change color back to black

The color will remain red. This is the case for all default options. I think it's related to the value=false change, see fffa6dd

1. Hit enter three times.

Expected: Cursor moves down one line after every enter, ending on the third line.
Actual: Cursor stays in place.

If you click into the editor after the typing, the cursor will jump to the correct position. Also, editor.getDelta() does yield the correct delta. Unfortunately this makes it pretty tough to automate this in webdriver.

1. Type '123abc'
2. Highlight 'abc' and set it's size to 'huge'.
3. Move your cursor over 123.

The dropdown's value should switch to 'Normal' but it remains 'Huge'. The editor's delta is correct though.

This is more than just a cosmetic issue, because if you were to highlight '123' with the intention of making it 'Huge', you wouldn't be able to (it's technically already selected and selecting it does nothing). To force the matter, you currently have to first set the size to something other than 'Huge' or 'Normal', and then switch back to what you actually want.

Once it has stabilized, we should document all the options that the Scribe constructor accepts.

Browser: Chrome 26

Steps to reproduce:

1. Type the text "abc\ndef"
2. Highlight "ef" and apply a background color.
3. Highlight "abc\nd" and hit delete.

Expected Result
"ef" with the previously applied background color.

Actual Result
"ef" with no background color.

Typing a character into Scribe on Firefox 20 yields the following error:

NotFoundError: Node was not found.

The referenced line is in scribe.all.js, so it's probably easiest for you to just check it out yourself. The error is reproducible on both beta.stypi.com and the head of the Scribe repo.

Let me know if you need any further info.

Start a new note, type "hello", then hit backspace 5 times. After that, hit backspace again and you'll see a revision was created, this is presumably because the \n is being deleted with the 6th backspace. After that, no syncing happens when you type.

If the document is long enough that the scroll bar is introduced, and if you are scrolled to the bottom, pasting text anywhere within the current view seems to automatically reset the scroll position to 0, at the very beginning of the doc.

If editor's style is customized, the cursor container is off (showing cursors in the wrong place)

Chrome 26.

1. Type 'a' into the empty document.
2. Delete 'a'.

Expected: "\n"
Actual: "\n\n\n"

Hit this on beta.

Steps to reproduce in Firefox 17.0:

1. Type some text in the scribe editor.
2. Press Ctrl+A to highlight all the text.
3. Press backspace to delete all the highlighted text.
4. Start typing

Note that after backspacing out, no text entry is allowed.

specifically, if you use APPLE KEY + (direction) to get to the beginning / end of the document or line the cursor doesn't update, presumably because you are not listening to these keystroke combos, or whatever.

To reproduce:

• Type two lines of text; begin the second line with a tab.
• Select both lines.
• Apply strikethrough or underline.

Expected behavior:

• Both lines will have strikethrough or underline applied.

Actual behavior:

• Only the first line does.

If the following lines do not begin with a tab, Scribe behaves as expected. However, if leading tabs are subsequently deleted, so that you only have lines with no leading tabs, the error behavior described persists.

1. 'abc'
2. Highlight 'c', click the bold button.
3. Mousedown after the 'b', drag across through 'a'. *Though we're just highlighting 'ab', it's necessary that there is no other mouse event (such as a click) before hand.

Expected: The bold button is not activated, and clicking it applies bold to 'ab'.
Actual: The bold button is activated, and clicking it does nothing.

The hot keys work fine. As does highlighting in the other direction, i.e., highlighting 'a' then 'b'.

1. "abcd\nabcd"
2. Style both "cd" substrings with the color red.
3. Place cursor before \n at index 4 and delete the \n.

The {color: 'red'} attribute is lost on the second "cd". Occurs in Chrome; Firefox is fine. I've added a test for this in the delete suite, which should help prevent regressing any more (it's been discovered/fixed before; see issue #12.

On beta, to reproduce:

1. Type the text "abc\ndef"
2. Highlight "ef" and apply a background color.
3. Highlight "abc\nd" and hit delete.
4. Ctrl+Z to Undo.

Expected result: "abc\ndef"
Actual result: "efabc\ndef"

Browser: Firefox 19.0

Steps to reproduce:

1. On the empty document, type "123".
2. Hit enter (insert "\n").

Expected Result:
"123\n"

Actual Result:
The lines "1\n", "23"

The tail is always pushed to the next line. This issue does not occur in Chrome.

Copying "\nHey" only pastes "Hey"

When Scribe first loads, the hyperlinking UI flickers in the editor. It seems like it needs to be display: none'd sooner or something.

This issue IS NOT isolated to firefox.
"debugger" break-point in fuzzer.rb prior to fuzzer logic.
attr_accessor :cursor_pos in selenium_adapter.rb

To reproduce:

1. Run: ruby fuzzer.rb chrome file://"your fuzzer.html path here"
2. Click back into your terminal once firefox/chrome is open (if firefox, click editor first)
3. In rdb: set autoeval
4. In rdb: adapter.move_cursor 10
5. In rdb: adapter.cursor_pos
6. In rdb: adapter.type_text "abcdef"
7. In rdb: adapter.cursor_pos
8. In rdb: adapter.doc_length

Expected behavior at step x:
5. cursor_pos should be 0 because it is an empty document
7. cursor_pos should be 6

Actual behavior at step x:
5. cursor_pos is 10
7. cursor_pos is 16

doc_length correctly outputs 6.

Issue has altered since fix in focus issue

Follow steps 1-7 below, the updated behavior is as follows:
Expected behavior: "abcdefZZZ"
Actual behavior: "aZZZbcdef"
Expected behavior: "abcdefZZZqq"
Actual behavior "aZZZbcdefqq"

Ubuntu 12.04 LTS / Firefox 19.0.2
"debugger" break-point in fuzzer.rb prior to fuzzer logic.

To reproduce:

1. Run: ruby fuzzer.rb firefox file://"your fuzzer.html path here"
2. Click back into your terminal once firefox is open
3. In rdb: set autoeval
4. In rdb: adapter.type_text "abcdef"
5. Click back into your terminal (firefox steals focus)
6. In rdb: adapter.type_text "ZZZ"
7. In rdb: adapter.type_text "qq"

Expected behavior: "abcdefZZZ"
Actual behavior: "aZZZcdef"
Expeced behavior: "abcdefZZZqq"
Actual behavior: "aZZZqqdef"

Additional notes:
At step 2, if you click the editor, and then alt-tab/click into the terminal, behavior is as expected.

This seems to be the case when the font is the only attribute, however. If you have {font: monospace, bold: true}, for example, then paste works as expected.

1. type "abc"
2. Move cursor to 0th index
3. Hit tab twice

Expected: "abc" gets indented in two tab widths
Actual: The editor loses focus after the first tab, and the URL bar gains it.

1. Type 'abc'
2. Highlight 'abc'
3. Copy 'abc'
4. Move cursor to the end of the line, hit enter, and paste it.

In Chrome: The pasted text assumes the font 'serif', but should remain 'san serif'.
In Firefox: Nothing is pasted.

1. "abc"
2. From index 3, hold shift and hit the left arrow 3 times.

Expected: "abc" is highlighted.
Actual: "b" is highlighted.

The behavior in Firefox and IE is that it highlights a character, advances the cursor; highlights a character, advances the cursor... making it impossible to highlight more than 1 char at a time.

1. Type "1\n2\n3"
2. Highlight "1\n2"
3. Hit tab.

Expected: "\t1\n\t2\n3"
Actual: "\t1\n\t2\n\t3"

On the advanced demo:

1. Set the cursor in the middled of the Link text.
2. Insert ab
   Expected: Liabnk is still linked
   Actual: 'b' does not have the link format

This does not happen in the index demo or if you type out Link, set the format and then insert the link. This indicates that the author module is probably the culprit.

1. type "\n"
2. Hit backspace.
3. type "a".

Expected: "a"
Actual: "\na"

See commit 418e0d5 for the accompanying test case.

This isn't really a bug in Stypi but it's a bug when integrated into Salesforce Chatter. The _ is being overridden somehow by certain Chatter pages and we need to guard it from this.