1034337 - need to make bidi.edit.delete_immediately true by default to restore previous backspace behavior

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Yuval Adam]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140605174243

Steps to reproduce:

Go to any input field in the browser (URL bar, search bar, or any input field on a web page) and type in a mixed English/Hebrew text, or paste the following example:

abcdefgאבגדהוזחhijkl

Set the cursor on or around the Hebrew text and try to delete characters using backspace.


Actual results:

It takes two backspace strokes to delete a single character.


Expected results:

Naturally, a single stroke should delete a single character.

Comment 1

[Alice0775 White]

Regressed since Firefox7

Comment 2

[Alice0775 White]

Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/0c94f01f53af
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110704 Firefox/7.0a1 ID:20110704211816
Bad:
http://hg.mozilla.org/mozilla-central/rev/3f27dc203e62
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110705 Firefox/7.0a1 ID:20110705030811
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0c94f01f53af&tochange=3f27dc203e62

Regressed by:
3f27dc203e62	Simon Montagu — Undefine caret bidi level during reflow instead of on text entry. Bug 664087, r=roc

Comment 3

[Simon Montagu :smontagu]

This is really expected behaviour -- if it didn't happen before bug 664087 that was a bug -- but you can change it by setting bidi.edit.delete_immediately to true in about:config

Comment 4

[Simon Montagu :smontagu]

See bug 328834 for more info

Comment 5

[Yuval Adam]

:smontagu sorry I fail to see how that solves this bug. Out of the box users who type in Hebrew will need to hit backspace twice to delete. Why isn't delete_immediately the default behavior?

Comment 6

[Simon Montagu :smontagu]

(In reply to Yuval Adam from comment #5)
> Why isn't
> delete_immediately the default behavior?

Please read bug 328834 for a full explanation. The spec linked to in that bug doesn't exist at the given URI, but there's a version of it at http://www.qsm.co.il/Hebrew/logicUI22.htm

That said, I see when experimenting with the testcase on different builds that what we are doing is not what the spec says: for example the caret doesn't move at all on the first backspace which undermines a large part of the rationale for the double backspace. ehsan, what is your opinion on the debate here and in bug 328834?

Comment 8

[Simon Montagu :smontagu]

I am leaning more and more to changing our behaviour here, especially since we already did so without noticing for some time, and changing back is perceived by users as a regression (here and in bug 1057552). Not to mention for interoperability with other browsers and mobile OSs.

There are a number of possibilities:

1) Remove bidi.edit.delete_immediately and the logic handling it completely.

2) Set bidi.edit.delete_immediately to true by default

3) Set bidi.edit.delete_immediately to true by default on some platforms (e.g. mobile) only

Any others?

Comment 9

[(no longer active)]

I think we should switch bidi.edit.delete_immediately to true by default.  That seems to be the least surprising UX here.  Our current behavior is definitely broken.

Comment 10

[Simon Montagu :smontagu]

OK, let's do that. Try push at https://tbpl.mozilla.org/?tree=Try&rev=fb84895fb960.

I've filed bug 1067788 and bug 1067796 on other issues that I noticed with the caret in bidi text.

Comment 11

[Simon Montagu :smontagu]

I'm actually pleased that this broke tests, because I suspected that there weren't any tests for this behaviour :)

The "Tests for bug 419406" in layout/generic/test/test_backspace_delete.xul need to set bidi.edit.delete_immediately back to false (or, better, test the behaviour with both values of the pref).

Comment 12

[(no longer active)]

(In reply to Simon Montagu :smontagu from comment #11)
> I'm actually pleased that this broke tests, because I suspected that there
> weren't any tests for this behaviour :)

Haha, me too!

> The "Tests for bug 419406" in layout/generic/test/test_backspace_delete.xul
> need to set bidi.edit.delete_immediately back to false (or, better, test the
> behaviour with both values of the pref).

Let's do the latter.

Comment 13

[Simon Montagu :smontagu]

Attachment: Patch 1: update tests

This tests deletion with the pref set to both true and false, and also adds a new test so that we are testing Backspace as well as Delete.

Comment 14

[Simon Montagu :smontagu]

Attachment: Patch 2: set the pref to true by default

Comment 15

[Simon Montagu :smontagu]

Try push for those two patches: https://tbpl.mozilla.org/?tree=Try&rev=0396ebcb7051

Comment 16

[Simon Montagu :smontagu]

https://hg.mozilla.org/integration/mozilla-inbound/rev/434e148f58c1
https://hg.mozilla.org/integration/mozilla-inbound/rev/8c737d160d5c

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/434e148f58c1
https://hg.mozilla.org/mozilla-central/rev/8c737d160d5c

Comment 18

[budabass]

Not really sure about the reporting a regression bug in bugzilla, but this bug reproduced for me after installing Firefox 34.0.5 on Linux Mint 16 (today, Dec 13th 2014).

I used the following method to install the new Firefox version: http://www.libre-software.net/how-to-install-firefox-on-ubuntu-linux-mint

As stated previously by Yuval:

Steps to reproduce:
1. Enter Hebrew text in the search bar / URL bar. For example: פיזבאז
2. Press backspace

Actual Result:
For each two backspace keystrokes, one character is deleted.

Expected:
Each keystroke deletes one character,

I switched the bidi.edit.delete_immediately Boolean to True, which resolved the issue. This should be True by default - if it indeed does not affect the behavior of other components (everything seems to be working fine for me after the change, so far.

Comment 19

[Yuval Adam]

As far as I can tell neither of the patches have actually landed in Firefox 34. It's unclear to me if they should have or not.

Comment 23

[Amir Meiri]

Hi,
Sorry to barge in on this, but

Comment 24

[Amir Meiri]

[sorry about that goof above, couldn't find the delete function]
Hi,
Sorry to barge in on this, but I fail to see the *exact* connection between bidi.edit.delete_immediately and the problem that Yuval Adam has reported.
The way I understand it bidi.edit.delete_immediately is supposed to offer alternate behaviors of backspace when deleting characters _between_ _direction_ _boundraries_. In other words: it's only supposed to affect a backspace key pressed when the text in front of the cursor was written in one direction (say, left-to-right) and the text in rear of the cursor was written in the other direction (say, right-to-left).
In this case the description is of something *else*: when deleting hebrew text, even if there is _no_ change in direction, _every_ character deletion requires _two_ backspace clicks.
Or am I missing something here?

Comment 25

[Yuval Adam]

(In reply to Amir Meiri from comment #24)
> In this case the description is of something *else*: when deleting hebrew
> text, even if there is _no_ change in direction, _every_ character deletion
> requires _two_ backspace clicks.

Well, clear the URL bar and type a Hebrew string.
If you try to delete from the end of that string indeed you get the double backspace problem.
However, if you move the cursor to the middle of the string, you get proper single backspace behavior.
So, there seems to be an implicit direction change at the end of a bidi string.

In any case, this bug still exists.

Comment 26

[Simon Montagu :smontagu]

(In reply to Amir Meiri from comment #24)
> In this case the description is of something *else*: when deleting hebrew
> text, even if there is _no_ change in direction, _every_ character deletion
> requires _two_ backspace clicks.
> Or am I missing something here?

You're 100% right, that is what Ehsan and I meant above when we agreed that the current behaviour was broken. The bug still exists only if you see it in a nightly build, or with bidi.edit.delete_immediately set to true in about:config

Comment 27

[Amir Meiri]

OK, I see what you mean Yuval. I didn't consider the end-of-line condition to be a direction switch, but I guess that's potato/potahto.

Comment 30

[bahram0110]

Hello dears
This bug status is resolved
I use latest version of firefox (34.0.5)
It is not resolved yet.

Comment 31

[Assaf]

I have bidi.edit.delete_immediately set to false and it still happens in the address bar and search inputs, seems resolved in web pages themselves.
FF 34.0.5 latest update.

tried to change it to true it didn't make a difference.

I still need two backspaces to delete one hebrew character in address bar and search input.

Comment 34

[sakura1743]

I changed the flag manually and it seems to have solved the problem but after this I am experiencing a bug that I am not sure if it is related to changing this flag or not.
When I have multiple tabs open, sometimes the tabs wont open when I click on them, meaning that Firefox shows that a new tab is clicked by bringing it forward but the page under the tab remains from the previous opened tab. 
Does anybody know what is causing this? 
p.s. Hardware acceleration is turned off in my Firefox settings. Everything else is set to default.