60712 - Flash edit text fields input causes browser to go back (upon hitting the delete key)

Status: VERIFIED DUPLICATE of bug 60102

(Core Graveyard :: Plug-ins, defect, P1)

Description

[Troy Evans]

While in an Flash edit text field and you hit the "backspace" the browser goes 
to the previous page. The desired response should be deleting the text/white 
space in the text field.  

This is a huge usability issue and breaks all content.

Comment 1

[Brian Nesse (gone)]

This is the same as bug 58957 -- Mac plugins do not receive key events. The 
backspace key is being sent to the window, not the plugin. This causes the 
browser to "go back".


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

Comment 2

[shrirang khanzode]

But this bug also happens on windows (1211).

Comment 3

[Brian Nesse (gone)]

Then I suppose that either the plug-in window isn't handling the delete key, or 
the main window isn't passing it on. adding saari who is already on plug-in 
events and reopening.

Comment 4

[shrirang khanzode]

This is fixed with saari's checkin to 58957. I have verified this on the trunk 
builds on all platforms(win,mac,linux). Need to verify on branch builds.marking 
FIXED.

Comment 5

[shrirang khanzode]

spoke too soon, works fine on mac and linux but still happens on windows. 
Changing OS and platform to reflect this.

Comment 6

[saari (gone)]

And this is why I want to unify plugin event handling.

Is this something we need for 6.01?

Comment 7

[av (gone)]

It is not on this list http://slip/projects/seamonkey/main-rel-list.html
How hard is the task?

Comment 8

[saari (gone)]

Actually, it looks easier than I thought, I'm doing a build with a potential fix
right now.

Comment 9

[av (gone)]

Can the link I just posted be viewed from outside? If it can, we should probably 
turn this bug report into 'confidential'.

Comment 10

[shrirang khanzode]

changing status: confidential

Comment 11

[saari (gone)]

Attachment: this patch fixes the problem (patch is for branch)

Comment 12

[Angela Butler]

Added branch accept to status whiteboard.  Chris, please check into the branch 
ASAP. Thx
.Angela...

Comment 13

[ekrock's old account (dead)]

Flash crasher or backward incompatibility bug. Nominating for nsbeta1 as
high-quality plug-in support is a priority for embedded applications.

Comment 14

[shrirang khanzode]

are we not fixing this on the branch ?

Comment 15

[Peter Lubczynski]

Isn't this already check-in/fixed? 

Comment 16

[saari (gone)]

I thought it was checked in...

Comment 17

[karnaze (gone)]

moving to m0.9

Comment 18

[Peter Lubczynski]

I think this is checked-in on the trunk too. Marking FIXED to trigger verify.

Comment 19

[shrirang khanzode]

This is *not* working for me on the windows trunk build 20010329. 
This is still not checked in the trunk...my guess.
I just tried it, The browser still goes back (to previous page) after hitting 
backspace in flash textfield. I am  reopening... 

Comment 20

[shrirang khanzode]

added test url...

Comment 21

[Peter Lubczynski]

Chris, can you migrate your changes from the branch to the trunk?

Comment 22

[saari (gone)]

I could swear this is in the trunk, but I'll double check as soon as my windows
build is done.

Comment 23

[saari (gone)]

okay, I suck, looks like I never did get this on the trunk

Comment 24

[saari (gone)]

no, changes look like they're in the trunk already.

And I tried this on my WinNT mozilla buiild from last night and it does not go 
back for me... what url and OS are you using where you still see this?

Comment 25

[shrirang khanzode]

url : http://slip/shrir/flashedit.html

Am using today's trunk on windows NT (2001040204). The previous page in history 
loads when I press 'backspace' key. Still happening for me.. :(

Comment 26

[Peter Lubczynski]

Reassign to Chris Saari as he knows what's up with this bug.

BTW, this is happening to me on my trunk pull.

Comment 27

[Peter Lubczynski]

Attachment: first try at a fix for this using #ifndef XP_WIN

Comment 28

[Peter Lubczynski]

Since Windows uses child windows, plugins will get native events anyway and 
don't need to get them through the DOM. The patch above makes it such that the 
events are only sent to the plugin on non XP_WIN platforms and consumed on 
others.

Question: Should this be XP_PC to include Linux?

I haven't done much testing yet, I don't know what regressions this may cause.

Comment 29

[shrirang khanzode]

Works on linux ..this is windows and windows only ! :-)

Comment 30

[Peter Lubczynski]

Chris, back into my court as I have a patch for this. Do you remember there 
being an issue with backspace before?

I think this is the correct thing to do. All events on Windows should come 
through the OS and not the DOM.

Can I get some reviews?

Comment 31

[Marc Attinasi]

Peter, why dontcah put in some comments on why WIN doesn't want that code?!?
[s]r=attinasi

Comment 32

[saari (gone)]

r=saari if it works for you, but I'm a little concerned that I still don't see
the bug on Win2k...

Comment 33

[Peter Lubczynski]

That's strange. I'm on W2K and see it. Shrir saw it. I'll run through some more 
tests.

Comment 34

[Peter Lubczynski]

Patch checked in. Marking FIXED.

new revision: 1.207; previous revision: 1.206

Comment 35

[shrirang khanzode]

still seeing this problem. Confirmed with Peter...reopening..

Comment 36

[karnaze (gone)]

Reassigining to saari and moving to m0.9.1

Comment 37

[saari (gone)]

You *still* see this?

Comment 38

[shrirang khanzode]

yes on today's windows (0412) going to www.emailtrack.com and typing something 
in the flash textfield shows this problem.

Comment 39

[shrirang khanzode]

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

Comment 40

[shrirang khanzode]

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

Comment 41

[Peter Lubczynski]

Chris,

Yes, this is *still* happening. Flash textboxes are not child windows so I think 
we aren't consuming correctly. Could you take a look?

Comment 42

[Peter Lubczynski]

Rod,

How did you solve this problem for text boxes like the address bar?

Comment 43

[Peter Lubczynski]

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

Comment 44

[Peter Lubczynski]

Takeing over.

Note: This is not a bug in MFCEmbemd or viewer. Backspace works there and should 
work for embedding.

Comment 45

[Asa Dotzler [:asa]]

no reason to be ns confidential. fixing

Comment 46

[timeless]

fwiw, XP_PC is approximately XP_WIN || XP_OS2
http://slip/ and similar urls will never work from outside netscape's firewall, 
selecting the external site for url to aid non netscape users.

Comment 47

[Mike Kaply [:mkaply]]

Hmmm.

We have much worse problems on OS/2 than this right now.

Typing in the textareas doesn't work at all, and backspace does take you back 
similar to Windows.

I made code in nsObjectFrame.cpp XP_OS2 as well, but it doesn't help.

Is there any other keyevent code for plugins that is XP_WIN?

Comment 48

[Peter Lubczynski]

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

Comment 49

[Peter Lubczynski]

Michael,

Perhaps you need to tell the content to have focus like I did to fix this bug:

+    nsCOMPtr<nsIContent> content;
+    GetContent(getter_AddRefs(content));
+    if (content)
+    {
+      content->SetFocus(aPresContext);
+      return rv;
+    }

Comment 50

[Chad Austin]

verified dups