60102 - Backspace can't be used in a Flash form (goes back one page)

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P1)

Description

[Joe Duong]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001114
BuildID:    2000111404

The backspace key (shortcut for back 1 page in history) will act as a
"backspace" key in HTML forms, however, when used as a "backspace" key in a
flash form, it will go back in the history one page. This is very undersirable
as this will break EVERY flash movie that has text editing involved. I've tested
on Netscape6final (todays' release) and also M18, and todays' build (2000111404).

Reproducible: Always
Steps to Reproduce:
go to:
http://www.moock.org/chat/
enter some text in the "log in" field.
Now try to erase some characters with the backspace key

It will take you one page back in the history.

NB: If you default your browser to a blank page (about:blank) and then go
directly to http://www.moock.org/chat then you will have no history (hence, you
won't be able to press the back button anyways) then the flash movie functions
as expected and you are able to use the backspace key as a backspace key! :) In
other words, you have to have something in recent history for this bug to
reproduce, which is most of the time for most users! :)



Actual Results:  It takes me back a page in the history instead of deleting a
character in a flash form.

Expected Results:  Delete the previous character in a flash form.

Comment 1

[sairuh (rarely reading bugmail)]

hrm, shrir d'you see this? if this isn't Flash-specific, feel free to punt back
or send to...Event Handling?

Comment 2

[jlarsen]

Confirming This happends in all webpages if no text entry form box is selected,
an flash text entry isn't recongized obviously. Setting as Event Handling,
Confirmed critical. (who was the wise guy who thought backspace would make a
neat shortcut?)
Occurs in all MS windows platforms, can anyone test with non windows?

Comment 3

[jlarsen]

opps changing description :)

Comment 4

[shrirang khanzode]

assign: joki

Comment 5

[jlarsen]

A critical bug that hasn't been touched in almost 2 months??? :( sad

Comment 6

[joki (gone)]

Saari if working on plugin stuff and may have already hit this one.

Comment 7

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 8

[Claudius Gayle]

they might be dupes but bug 69981 refers specifcally to the design issue of why the hell
backspace goes back in history when alt/cmd [<-] works just fine.

If the way to fix this is to kill that shortcut then they're dupes. If somehow we can recognize
a flash textfield and fix it that way then 69981 lives on.

Comment 9

[jlarsen]

Just a thought shouldn't all shortcuts flow to flash if it is currently being 
used, as flash can capture many key combinations, and have they keys sent on to 
mozilla if they arn't used by flash. Isn't this the way netscape 4 does it?

Comment 10

[saari (gone)]

Yes, that is exactly the way it should, and does work. Flash isn't sending 
notification that it consumed the event.

I could make plugins always consume the event if they are in focus, 
behaving a little more like 4.x, but that would cause other bugs. People 
would complain that the browser commands wouldn't work when plugins 
are focused.

Comment 11

[Peter Lubczynski]

The consuming may be causing some other bugs where we get Mozilal context menus 
instead of the plugin ones. 

Brian, how did 4.x do this?

Comment 12

[Brian Nesse (gone)]

It appears to me that 4.x traps Ctrl and Alt key commands, and passes anything
else to the plugin.

Comment 13

[Peter Trudelle]

->moz1.0

Comment 14

[saari (gone)]

We could mimic 4.x by checking the key events in the object frame before we
dispatch to the plugin...

The only issue I see there is that some plugin writers are probably going to
want their own ctrl and alt bindings, and maybe even want to override the
browser ones. Having them set their event consumpution return value is still
better IMO, but we can certainly revert to 4.x behavior if they don't want to do
that. Might want to explain to them that it is effectively limiting themselves
though.

Comment 15

[jlarsen]

Until we fix the whole pluggin model, can we atleast remove backspace from being 
a hotkey for back. This is keeping mozilla from working in many websites.

Comment 16

[Stephen Ostermiller]

Another web site on which this is easy to test:
http://entries.the5k.org/673/index.html

Comment 17

[shrirang khanzode]

dup of 60712. reopen if u think this is different...

*** This bug has been marked as a duplicate of 60712 ***

Comment 18

[Boris Zbarsky [:bzbarsky]]

Since that bug is NS confidential... and this one has no reason to be.... 
reopening and marking dependency

Comment 19

[Boris Zbarsky [:bzbarsky]]

*** Bug 75972 has been marked as a duplicate of this bug. ***

Comment 20

[Peter Lubczynski]

In nsWindow::ProcessMessage we have code to check for backspace or return:

// check first for backspace or return, handle them specially 
//
if ((wParam <= 0xff) && (ch==0x0d || ch==0x08)) {
  result = OnChar(ch,ch==0x0d ? VK_RETURN : VK_BACK,true);
  break;
}

Chris/Kevin,

Is there some way we can tag this child window as being a plugin or detect 
the window is associated with a plugin and add a check to the conditional?

Comment 21

[Ian Tommins ('thelem')]

The only way you can fix this bug is to remove the backspace shortcut.

If flash takes the backspace key, then people wonder why they can't go back a page
If Mozilla takes the backspace key, then people can't delete things in flash.

We have a good shortcut for back anyway, and the back space key has no forward
equivilent. All that is needed is for someone to remove the keyboard mapping for
backspace.

I could attach a patch, but it would be so simple as to be just a waste of time.

Comment 22

[timeless]

iirc the opposite of backspace is shift-backspace

Comment 23

[Peter Lubczynski]

I believe it should be smarter than this. Backspace works in IE as back. Before 
sending off the backspace key, I think we can find a way to check if the child 
window has a plugin. 

Comment 24

[jlarsen]

No reason to copy a IE shortcut that is already pointless and can cause 
confusion in IE, I agree the plugin model needs fixing to allow plugins to 
capture events and have them not go to the browser, but seriously we should 
remove the shortcut first people, enough talk.

Comment 25

[timeless]

that's another bug, i'm almost positive it's already filed.

Comment 26

[jlarsen]

We really don't want to ship 0.9.1 with such a simple problem to fix.

Comment 27

[saari (gone)]

"Is there some way we can tag this child window as being a plugin or detect
the window is associated with a plugin and add a check to the conditional?"

Yeah, all of our nsWindows have a specific class, if it isn't one of those
classes, I think it is a plugin. This assumption is wrong if we create other
window classes, which I'm not aware of.

pterl, could you own this issue? I'm still pretty swamped

Comment 28

[Peter Lubczynski]

Takeing over and setting milestone to mozilla 0.9.1...

Note: This is NOT a bug in MFCEmbemd or viewer. Backspace works there. 

Could the chome be plugged in ahead of?

Comment 29

[Peter Lubczynski]

This is the same as bug 60712.

*** This bug has been marked as a duplicate of 60712 ***

Comment 30

[Ian Tommins ('thelem')]

Please read previous comments first, namely:

------- Additional Comments From Boris Zbarsky 2001-04-13 20:58 -------

Since that bug is NS confidential... and this one has no reason to be.... 
reopening and marking dependency

It is related to 69981 though, and may be a dupe of that.

Comment 31

[Peter Lubczynski]

Ok, I see what you mean.

In any case, I think I figured out how to fix this. Turns out the nsObjectFrame  
was never getting focus correctly. The call nsIWidget->SetFocus() tells Windows 
about focus but not Moizlla. When the plugin gets an NS_PLUGIN_ACTIVATE event, 
we need call nsIContent->SetFocus().

    nsCOMPtr<nsIContent> content;
    GetContent(getter_AddRefs(content));
    if (content)
      content->SetFocus(aPresContext);

I will test on Mac Monday and create a patch to try to get into 0.9 (pending 
drivers approval).

Comment 32

[Ian Tommins ('thelem')]

It is looking like bug 69981 is going to be fixed soon, which would fix this bug
for backspace. I don't know if a bug should be created for other shortcuts.

Comment 33

[Peter Lubczynski]

Attachment: patch to set focus on content in nsObjectFrame

Comment 34

[Peter Lubczynski]

Clearing milestone and nominating for Mozilla 0.9. 

Can I get some reviews for this patch?

Comment 35

[Chris Waterson]

[s]r=waterson

Comment 36

[Robert O'Callahan (:roc) (email my personal email if necessary)]

a=roc+moz for 0.9 (on behalf of drivers)

Comment 37

[Peter Lubczynski]

*** Bug 60712 has been marked as a duplicate of this bug. ***

Comment 38

[Asa Dotzler [:asa]]

setting TM to 0.9 (please excuse the tresspass, just trying to clear up the 0.9
buglists)

Comment 39

[Peter Lubczynski]

verbal r=attinasi

/cvsroot/mozilla/layout/html/base/src/nsObjectFrame.cpp,v  <--  
nsObjectFrame.cpp
new revision: 1.210; previous revision: 1.209

Marking FIXED. You should be able to type backspace in Flash forms now.

Comment 40

[Madhur Bhatia]

QA contact updated

Comment 41

[luis rincon]

verified on build 2000-11-16 and 2001-07-09