Fabric.js: iText Backspace causes WebKit browsers to go back in history

Created on 3 Nov 2014  Â·  40Comments  Â·  Source: fabricjs/fabric.js

See https://balmboo.com/product/dance-party/.

The WordPress plugin developer swears up and down that it's an issue with fabric.js and not his plugin.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

browser_bug itext

Most helpful comment

It actually crashes Safari 8 (Yosemite) for me, when I try to double-click newly-added iText... O_o

All 40 comments

WebKit means chrome?

Chrome Beta and OSX Safari.

Zack Philipps
Executive Director at Tribeswell, [email protected]

812.797.9545

On Mon, Nov 3, 2014 at 12:00 PM, Andrea Bogazzi [email protected]
wrote:

WebKit means chrome?

Reply to this email directly or view it on GitHub:
https://github.com/kangax/fabric.js/issues/1804#issuecomment-61510062

I'll try to replicate on OSX Safari, cannot take care of Chrome's Beta, when is released we will see.
Do you have a Safari version to check? or any?

Version 8.0 (10600.1.25) of Safari on Yosemite.

Appreciate it!

Zack Philipps
Executive Director at Tribeswell, [email protected]

812.797.9545

On Mon, Nov 3, 2014 at 12:08 PM, Andrea Bogazzi [email protected]
wrote:

I'll try to replicate on OSX Safari, cannot take care of Chrome's Beta, when is released we will see.

Do you have a Safari version to check? or any?

Reply to this email directly or view it on GitHub:
https://github.com/kangax/fabric.js/issues/1804#issuecomment-61511452

It actually crashes Safari 8 (Yosemite) for me, when I try to double-click newly-added iText... O_o

+1 happened to me as well.

Zack Philipps
Executive Director at Tribeswell, [email protected]

812.797.9545

On Thu, Nov 6, 2014 at 4:41 PM, Juriy Zaytsev [email protected]
wrote:

It actually crashes Safari 8 (Yosemite) for me, when I try to double-click newly-added iText... O_o

Reply to this email directly or view it on GitHub:
https://github.com/kangax/fabric.js/issues/1804#issuecomment-62056445

Is this still valid?
Can someone with safari test?
I do not have any webkit browser on windows.

The Safari bug isn't happening anymore. However, this is Chrome stable:

https://www.screenmailer.com/v/Vnf5DHa781sSArA

Can't you download Chrome on Windows?

i have chrome on windows and i do not have that bug.
When i saw your video, the "double click to edit" caught my attention.
May it be that you are loosing focus from the textbox with the double click?

Also looking at source:

  /**
   * Removes characters selected by selection
   * @param {Event} e Event object
   */
  removeChars: function(e) {
    if (this.selectionStart === this.selectionEnd) {
      this._removeCharsNearCursor(e);
    }
    else {
      this._removeCharsFromTo(this.selectionStart, this.selectionEnd);
    }

    this.setSelectionEnd(this.selectionStart);

    this._removeExtraneousStyles();

    this.canvas && this.canvas.renderAll();

    this.setCoords();
    this.fire('changed');
    this.canvas && this.canvas.fire('text:changed', { target: this });
  },

removeChars has no e.preventDefault or e.stopPropagation

That may also be cause of the problem.

Are you available for some test? do you own an iphone for some more tests?

I was wrong. The event is prevented and stopped.
Not happening in chrome from windows for me.
http://www.deltalink.it/andreab/fabric/iphone.html

I added on this experimental page an Itext.
I switched the handling of backspace from onKeyDown to onInput.
Would you please check if it makes any differences? i'm doing a bug hunting session on Itext/textbox and i would appreciate any help. I'm a windows guy, i will redempt one day, but for now testing outside windows is not easy for me.

I do have an iPhone, and I'd be happy to test on it. The link you provided seems to work fine:

https://www.screenmailer.com/v/tsAnOBtaEaBaiJo

Also works fine on an iPhone, but there are duplicate cursors (see the tiny blue one):

img_1122

does it jump or do you get any strange autozoom problem?

I noticed that moving the deleting on the onInput gives us also a nice automatic CTRL+Z feature that i personally do not dislike.

Does it happen to you to have accidentally double deletion?

The chrome does not go back anymore on its history?

Yes, on iPhone, the autozoom is weird. If I double-tap to edit, I have no problems because it fits the div in the viewport. If I just tap once, however, it zooms WAY in.

I have not seen any double-deletion. Chrome is working fine now. So is OS X Safari. No more going back in history. :)

@QasimK, @handersen, @Onassar any attention from you that have been active with iText is also appreciated.

I will try to switch to onInput for deletion back and forward and give a sense to this CTRL + Z free feature. Please when i post if you could give a shot to that simple test page and play a bit with it.

@angelim if possible follow here please.

@QasimK, @handersen, @Onassar, @angelim
The guys with an iphone can check at the same page
http://www.deltalink.it/andreab/fabric/iphone.html

1) it still does not jump
2) the caret is still there

i added 2 property to style: color transparent and text-indent -9999em

Just saw this other thread. This latest experiment works on my mac! Just confirming the environment on this thread as well:

Mac Retina Mid 2012 with OSX 10.9.5 on chrome 49.0, Firefox 44 and Safari 9.0.1. The keyboard layout is US International.

I've tested this on my iPhone 6 iOS9.3.

On the test page, the page does not jump like crazy as I had experienced previously. The caret is still there, however, as zackphilipps said, there is sometimes a much smaller blue caret.

Finally, sometimes the page does not centre properly on where you are editing the text. This sometimes happens when the text goes out of the bounds of your view. I would expect the view to move so that the caret is not right at the edge of the page but sometimes it is. This means when you then type you cannot see what you are typing any more since the page view doesn't follow the caret.

To better center we could try to move the textbox with the cursor.
Il 29 mar 2016 16:48, "Qasim K" [email protected] ha scritto:

I've tested this on my iPhone 6 iOS9.3.

On the test page, the page does not jump like crazy as I had experienced
previously. The caret is still there, however, as zackphilipps said, there
is sometimes a much smaller blue caret.

Finally, the page does not centre properly on where you are editing the
text. This sometimes happens when the text goes out of the bounds of your
view.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/kangax/fabric.js/issues/1804#issuecomment-202934376

@Kitanotori i mention also you here, for the ctrl + C problem under ie11.
Can you make more light on the japanese ime input problem?

@asturur I recommend installing Japanese IME and trying out yourself, because the problem is probably difficult to understand otherwise. The kana conversion box is not shown when and where it should be, and the characters are not even being added to IText, so I would say it's still totally broken for Japanese.

I'm for:

  • moving the textbox in the lower part of the fabricjs caret to allow align with the conversion box
  • moving the textbox with the position of the carte, so maybe browser will auto center, if not, is not something we can fix
  • trying to change the fontSize or the width of the textArea. this will maybe allow for a better auto zoom in function.
  • i just found out the compositionUpdate event that togheter with compositionStart and compositionEnd will give me chance to handle the japanese/chinese ime. Do not ask for RTL because i still do not know where to look for. One piece at time.

Keep in mind that all the hacks we do to just accomodate some particular browser behaviour may be useless when browser update.
So, happy to try to make everything work but if the iphone zooms too much or decides to render it's own caret anyway i will not be able to change it.

i will update you.

@asturur I share your frustration, but as Web developers, we should aim at supporting the most significant browsers and languages. I got IText with support for Japanese and cut-copy-paste working for Chrome, Firefox, Safari and IE11 with some hacks ( #2352 + some own customization in the mouse and keyboard event handling), but I would prefer IText working out-of-the-box.

@Kitanotori i solved ie11 copy using CTRL+C shortcut instead of the copyevent that does not trigger in hidden textbox on IE11. How did you solve it instead?

Also how did you solve the alignment of the textbox for the composition box?
Do you mind sharing some code? (even by email, let's not pollute this thread too much)

@asturur In addition to #2352 I changed the style of the hidden textarea, because if I remember correctly, certain CSS attribute values caused events not to fire (was maybe a Safari problem, don't remember clearly anymore). Anyway, this.hiddenTextarea.style.cssText = 'position: absolute; left: -1000px; top: -1000px'; seemed to fix things.

I removed copy and paste event listeners, i.e.

    // fabric.util.addListener(this.hiddenTextarea, 'copy', this.copy.bind(this));
    // fabric.util.addListener(this.hiddenTextarea, 'paste', this.paste.bind(this));

then I added a ctrl+c listener, i.e.

  _ctrlKeysMap: {
    65: 'selectAll',
    67: 'copy', // <=
    88: 'cut'
  },

I commented out e.preventDefault() from onKeyDown and paste because they prevented events firing correctly. To the beginning of cut handler I added an ugly browser specific hack because couldn't figure out a neater solution:

    var user_agent = navigator.userAgent.toLowerCase();
    if (!(user_agent.indexOf('msie') > -1 || user_agent.indexOf('trident') > -1)) return;

If I remember correctly, these were the changes I made in addition to the patch. I tried all kinds of combinations regarding the event handling, and this gave me the largest browser coverage (couldn't get clipboard handling working in Edge and didn't test IE versions below 11, so can't confirm those).

My overall conclusion was that the browsers don't provide standardized and usable Clipboard API support, so it is best to try to get the default copy-cut-paste event processing working and try to avoid complicated event handling and manual clipboard manipulation functions as much as possible.

Hello, i implemented the moving textArea for the japanese/chinese IME.
I would like to know if on mobile browser the zoomed page follows the text input caret, if the japanese input method is somewhat acceptable, and if the iphone autozoom function has improved.

http://www.deltalink.it/andreab/fabric/iphone.html

Thanks!

@asturur Did you test if with Japanese IME? Not working (Win 10, Firefox).

yes i tested. write n, write o, you should get the "no" hiragana. then press space to see it change, then press again to see the listbox of all available choices.

@asturur Can't write anything, not even plain English. I guess the events are not firing. Did you test with Firefox?

I uploaded wrong file, now i corrected it.
This is how it is supposed to work:
japaneseime

@sapics any help or suggestion?

@asturur It works great! I am using Google Chrome in Windows8.1.
Is it for iphone? Sorry, I don't have iphone.

It is for everyone that may use it, from desktop or phone. I'm interested in understanding what a japanese user expect from this kind of IME. I noticed that in the textbox you can write as you want and then you can go right and left with keys and change just some words. This cannot be done as of now because of some event limitation. I want to know from a japanese guy if that demo is enough to say that japanese language is supported.

@asturur Japanese IME seems to work mostly fine now, but 'cut' does not work. Also, occasionally there seems to be some issue with delete when using IME (the cursor moves as it should but the deleted character does not disappear).

@handersen, regarding #2823 I applied some fixes in this demo page. Would you be so kind to test it?

http://www.deltalink.it/andreab/fabric/iphone.html

@Kitanotori i made some changes to cut/copy/past that had a general error on handling cut on chrome, firefox, and on IE family copy event was not really working.

Sadly the main point of this topic, the backspace is not fixed yet. I really need help from you all to catch errors i may have introduced, if you have time of course.

@asturur My local Fabric.js is not currently in sync with the main branch, and I made the changes directly to dist/fabric.js. I will try to post the changes to my fork in near future. My current project is quite Fabric.js-centric, so I'm happy to contribute.

@asturur regarding #2823 I have tested again. It is much better.

Still an issue with edge and Firefox

Edge
If you select a part of the text by marking from left to right and then overwrite the first character is removed and instead the first marked character is present.

Reproduce (Tested in Edge 25.10586)
1 in your test http://www.deltalink.it/andreab/fabric/iphone.html using Microsoft Edge

  1. Mark the characters thin in the word something.
  2. key 1234
  3. In edge the result is somen234g instead of the expected some1234g

Note - if you select/mark the text from right to left it works in edge. Backspace issue seems to be solved. Both issues works in Chrome.

Firefox
Text input seems to be blocked completely in your test ?

Sorry i uploaded wrong file again. Firefox is ok again. I wonder how chrome could work...

Both Firefox and Chrome works for me with your test program http://www.deltalink.it/andreab/fabric/iphone.html

Still the Edge issue when marking from left to right as described above. This is minor though.
Really improved with this.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

semiadam picture semiadam  Â·  3Comments

bevacqua picture bevacqua  Â·  4Comments

lyzs90 picture lyzs90  Â·  3Comments

mlev picture mlev  Â·  3Comments

keanass picture keanass  Â·  5Comments