Closed Bug 181198 Opened 22 years ago Closed 21 years ago

Browser goes Back when trying to delete Japanese text I have entered and confirmed.

Categories

(Camino Graveyard :: HTML Form Controls, defect)

Product:
Camino Graveyard
Component:
HTML Form Controls
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Camino0.8

People

(Reporter: bjkennedy, Assigned: mikepinkerton)

References

(
URL
)

Details

(Keywords: intl) 

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021119 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021119 Chimera/0.6+

When I type Japanese into any field on any page, and then hit return to confirm
it, and then press delete, the browser goes back as well as deleting the
charcter. This happens every time. However, it only happens once the characters
are confirmed (i.e., if they are still underlined because you are still
selecting the correct kanji for them, it works fine). Note this does not happen
in regular Mozilla.

Reproducible: Always

Steps to Reproduce:
1.Make sure you are not at the beginning of a series of pages; the back button
must be able to bring you back somewhere.
2.Enter some japanese characters, followed by return to confirm them.
3.Press delete.
Actual Results:  
The browser goes back to the previous page. If you hold it down, it will go back
again and again.

Expected Results:  
Just deleted the character.
WorksForMe using Chimera/2002111204.
Keywords: intl
I can reproduce this using 2002112004.

Go to www.google.co.jp. Switch to Kotoeri. Type:

NIHONN<space><retuen><backspace>

in the query field. And Naigator sends me back to previous page.

It also happens with Chinese pages using TCIM.
Confirmed using Chimera/2002111204 to perform the steps in comment 2.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Could be the same bug as 183611. Seems like the state is getting messed up after
the input of composed characters maybe. Question: When you hit return to confirm
a japanese composed character, do you normally expect the focus/cursor to stay
in the text field? Does it stay there if you keep typing normal characters
instead of hitting delete? If you type a composed character, hit return, then
type a non-composed character, then hit delete, what happens?
> When you hit return to confirm a japanese composed character, 
> do you normally expect the focus/cursor to stay in the text field?

Yes. So we can continue typing into the field. And Chimera actually does keep
the focus in the text field after confiming the input.

> Does it stay there if you keep typing normal characters
> instead of hitting delete?

Yes.

> If you type a composed character, hit return, then
> type a non-composed character, then hit delete, what happens?

The character is deleted. Page stays. The bug ONLY happens when backspace key is
 pressed right after confirming input with return key.

This bug is THE most annoying problem in Chimera regarding CJK page use. It will
be great if it's fixed soon.
It occurs on chinese too, when inputting a chinese character, input, hit
<space>, <enter> then <delete> must cause chimera goes back, and input, <enter>
then <delete> cause chimeta goes back for some chinese characters.
Alas still happening for me on 2003010104.
Very annoying in Hotmail!
major for intl
Severity: normal → major
Is there any progress on this bug? It is the single biggest issue when using
Camino right now. For me at least.
yes, this is a big deal
Assignee: bryner → pinkerton
Target Milestone: --- → Camino0.8
*** Bug 215678 has been marked as a duplicate of this bug. ***
*** Bug 183611 has been marked as a duplicate of this bug. ***
*** Bug 199359 has been marked as a duplicate of this bug. ***
The problem was getting so incredibly annoying that a certain indivual in Japan created an 
Application Enhancer Module with the sole purpose of patching this bug.

http://hetima.com/camino/index.html

The source is not there, but perhaps someone could contact this person and ask how he did it?
I think that removing the "backspace = go back" is the best thing to do. We
already have multiple options for a user to go back (toolbar items, 
command+arrows and contextual menu), so I see no real problem in removing it.

This is what I found in BrowserWindowController.mm line 1599>1606

// map delete key to Back
- (void)deleteBackward:(id)sender
{
  if ([[NSApp currentEvent] modifierFlags] & NSShiftKeyMask)
    [self forward:sender];
  else
    [self back:sender];
}

Would removing this part of the code solve the problem?
i think you'd have a mutiny if you removed this. we put it in because of
overwhelming request from the community. I, in fact, didn't want it at first,
but now if you take it away from me, i'll kill you ;)

the right thing to do is to fix our IME.
Could we have an option in preferences to disable it? Please!

In fact, I understand Western lanugage speakers will never understand how
anonying it is.  If you have typed 3 to 4 thousand words in a forum, and you
have hitted the backspace for correcting a typo.  Dada!  All your well thought
opinion and the carefully chosen words are gone! completely gone!  We asian
languages users face this tragedy daily!
no, we should fix the bug. no prefs to workaround bugs.
Come on people fix this bug, users driving mad by this. This bug has been here
for almost one year now?

I know removing the the code I mentioned in Comment #16 would be hard on a lot
of users but please don't forget that Chinese and Japanese users have no
alternative to fall back on with their problem. While the people who will lose
the "backspace=go back" option have a zilion alternatives:
- the toolbar buttons
- contextual menu
- command arrow key combination
- command [ and ] key combination.
- and the (blody) backspace key

I'm serious here why in heavens name would a user want 6 different methods to go
back and forward between pages? I don't get it. The whole filosofy of Camino is
to keep things simple and small right. With all respect, in my opinion having
six ways to do one thing is rediculously over complicated. Especialy if one of
those ways creates some serous problems amongst Asian users of Camino.

ps: Mike if you are going to wait longer on fixing this (or getting a fix) Asian
people are going to kill you and I wont be able to help you ;)
This problem does also affect French-speaking users, who write a lot of letters
with diacritical marks (compound characters) : é, à, è, ê, ç, É, Ê, È, Ç, etc.

German users also use such characters.

However, I think we have to keep backspace as a shortcut for previous page. No
workaround and fixing the real bug is much better, as Pink says.

Jasper: for people using other keyboards as the US (english ?) one, you can
forget the command [ and ] key combination :-(
Well, what do you people think of Command-Delete?  It sounds like a good middle
ground type solution.  

I mean, really people, having Delete for quick key would be like saying that if
you weren't in a text field, q should quit your application or w should close
your window. (Picture how people would react then ;-))  I don't care what button
makes you go back as long as the command key goes along with it like 50 million
other quick keys.

Safari is being a bad example (in my opinion) of being a good Mac OS program
here.  So now, when you hit the delete button in the Finder, what does it do?
...not the same as Windows (just play along even though the delete and backspace
keys are different)...It's like a safty net having to hold down the command key
to delete something, and then you don't have to deal with the "are you sure you
want to delete this?" dialog. And then also, there would be no worrying about
not having "[" on some keyboard setups.

For those users worried about losing your text you typed, make sure to hit
forword and you should be put back where you were left off when typing, albiet a
bit dazed.
This is also the most annoying bug to Korean camino users.
*** Bug 192117 has been marked as a duplicate of this bug. ***
Hey. We have 10 votes on this one already. Do the votes mean anything?

Frankly, I don't care how the Go Back shortcut is going to be. Just fix this
one. Use shift-control-option-command-delete if you want. Remove it is OK, too.
I just don't care. This bug is so bad that all of the Chinese users I know
abandened Camino just for this. I would have switched to Safari if not for
bookmark keyword and type ahead search.

Please... I beg you... fix this.
I'd be willing to look at this, but I have no idea how to replicate it.  I tried
to follow the directions in comment 2, but I don't know what Kotoeri is or how
to switch to it. :(

Could somebody provide very explicit instructions (maybe even point to a page
with pictures) walking me through setting the right language/input text/whatever
else?
Steps:
1. load www.google.com, focus the text field
2. Type option-e to start an actute accent; you should see a hilighted accent char.
3. Hit backspace. Note that Camino goes back, rather than deleting the accent.
David, thanks for your willingness to work on this. If you can fix it quickly,
that'd be great. If not, would you consider putting up  at your build site a
build with backspace key removed from the set of keys bound to 'page back'? That
will certainly help attract back a lot of people who know Camino is a lot faster
than Safari but can't use it for this very bug.

To be honest, I found it hard to believe that so many people wanted 'backspace'
key to act as 'page back' (comment #17). On the other hand, I can fully
understand the frustration of many people (esp. CJK). 
please, no workarounds, no hacks to turn it off. the right thing is to fix the
bug. fwiw, safari has the feature as well.
I didn't ask for turning it off. I do want this bug to be fixed properly.  I
just asked David if he'd consider putting up his _private_ build with that
turned off so that people who can't wait any longer for this bug to be fixed
properly  can download it, instead. If I had a Mac, I'd build one and put it up
at my web site.

pinkerton isn't the only one who really likes delete = back ;-)

Here's another fun feature of this bug. Try this:
1. set home page to www.google.com
2. set load home page in new windows
3. create a new window
4. do simon fraser's test: Type option-e to start an actute accent; you should
see a hilighted accent char.
5. type Delete. Note that *nothing* happens.
6. Click in the text field
7. Type delete again. Now the temporary "place holder" symbol for the accented
character disappears.

FWIW I assume US-English keyboard, option-e might be different on other keyboards.

So it seems like the focus isn't in the text field in the "in between" moment
when you are composing a multi-key character.
this probably qualifies as bugspam.  sorry.

as I see it, here's the problem:
if you press the key "e", followed by backspace, the backspace generates a call
to  nsTextEditorKeyListener::KeyDown (an empty method) followed by a call to
nsTextEditorKeyListener::KeyPress.

If you press "ctrl-e", followed by backspace, that first call to
nsTextEditorKeyListener::KeyDown happens, but NOT the call to KeyPress.  The
next (as near as I can tell) and final event handler is in
BrowserWindowControler.mm of Camino, which triggers the "go back" problem.

I've played with inserting a call in KeyDown to check if we're in the middle of
an IME event then calling KeyPress.  It is not ideal - either I can't clear the
composition state correctly, or we the message continues to bubble up to
BrowserWindowController.  I'm more interested in figuring out why the event
listener is not having its KeyPress function called (not sure if the editor has
lost focus or what).  

I'm still trying to figure out how events are groups/passed/managed.  Hopefully
somebody will read this and have an "a ha!" moment.  
Focus is NOT lost in Mozilla Firebird. So have we added something between the OS
and nsTextEditorKeyListener::KeyPress that's not there in normal mozilla?

perhaps a hack would be if in BrowserWindowController, we could somehow detect
that we're in the middle of composing a character and disable the back function.
This is different from firebird because there we're using carbon TSM stuff. In
cocoa, we have to translate cocoa typing events into TSM-like calls into gecko.
There's a bit of an impedence mismatch.
I've found another case where this happens. If you're submitting a form and you
'stop' the form load, the flashing cursor still appears in the text field.
Hitting 'backspace' at this point BOTH deletes the character, and goes back to
the previous page.

However, if after stopping the page load you click in the text field, even if it
doesn't move the insertion point, 'backspace' will only delete the character as
expected.

I've put together a set of very simple web pages to demonstrate the problem:
http://onca.catsden.net/~chris/camino-test/backspace1.html
i noticed that pressing any other key (like an arrow key) will reset it so that
backspace then works correctly. just a minor workaround.
re comment #34, sfraser: where does this translation happen?
nsChildView.mm
i have a patch for this that i'll land today. my limited testing is promising.
Status: NEW → ASSIGNED
i have checked in a real fix for the japanese text input problem in cocoa
widget. yay!

the bug with diacriticals (option-e, e) is still there and is a related but
different issue which i cannot easily resolve. as a result, i have put a hack in
the bwc to check that a text field isn't focused before going back. it serves as
a catchall for all the IME-related bugs we have in this area. As the diacritical
issue is a different problem, i will open a new bug for it.

marking this fixed.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Can you upload the patch for mozilla code archaelogists? 
no, but you can look it up with bonsai. the fix was in
widget/src/cocoa/nsChildView.mm
Now it works file with Camino/2004020608.
critical bug since 2002-11-04 is fixed at last.
excellent coding!
Way to go Pinkerton!  Thanks for the hard work!

I can type in Camino now!
You need to log in before you can comment on or make changes to this bug.