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

VERIFIED DUPLICATE of bug 60102

Status

()

Core
Plug-ins
P1
blocker
VERIFIED DUPLICATE of bug 60102
17 years ago
17 years ago

People

(Reporter: Troy Evans, Assigned: Peter Lubczynski)

Tracking

Trunk
mozilla0.9.1
x86
Windows NT
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
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.
Keywords: flash

Comment 1

17 years ago
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 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 2

17 years ago
But this bug also happens on windows (1211).

Comment 3

17 years ago
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 4

17 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 5

17 years ago
spoke too soon, works fine on mac and linux but still happens on windows. 
Changing OS and platform to reflect this.
Status: RESOLVED → REOPENED
OS: All → Windows NT
Hardware: All → PC
Resolution: FIXED → ---

Comment 6

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

Is this something we need for 6.01?

Comment 7

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

Comment 8

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

Comment 9

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

Comment 10

17 years ago
changing status: confidential
Group: netscapeconfidential?

Comment 11

17 years ago
Created attachment 22522 [details] [diff] [review]
this patch fixes the problem (patch is for branch)

Comment 12

17 years ago
Added branch accept to status whiteboard.  Chris, please check into the branch 
ASAP. Thx
.Angela...
Whiteboard: [branch accept]
Flash crasher or backward incompatibility bug. Nominating for nsbeta1 as
high-quality plug-in support is a priority for embedded applications.
Keywords: nsbeta1

Updated

17 years ago
Blocks: 65204

Comment 14

17 years ago
are we not fixing this on the branch ?
(Assignee)

Comment 15

17 years ago
Isn't this already check-in/fixed? 
Keywords: verifyme

Comment 16

17 years ago
I thought it was checked in...

Comment 17

17 years ago
moving to m0.9
Target Milestone: --- → mozilla0.9
(Assignee)

Comment 18

17 years ago
I think this is checked-in on the trunk too. Marking FIXED to trigger verify.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
Whiteboard: [branch accept]

Comment 19

17 years ago
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... 
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 20

17 years ago
added test url...
(Assignee)

Comment 21

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

Comment 22

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

Comment 23

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

Comment 24

17 years ago
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

17 years ago
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.. :(
(Assignee)

Comment 26

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

BTW, this is happening to me on my trunk pull.
Assignee: av → saari
Status: REOPENED → NEW
Keywords: nsbeta1, verifyme → nsdogfood
(Assignee)

Comment 27

17 years ago
Created attachment 29469 [details] [diff] [review]
first try at a fix for this using #ifndef XP_WIN
(Assignee)

Comment 28

17 years ago
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

17 years ago
Works on linux ..this is windows and windows only ! :-)
(Assignee)

Comment 30

17 years ago
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?
Assignee: saari → peterlubczynski
Keywords: patch

Comment 31

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

Comment 32

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

Comment 33

17 years ago
That's strange. I'm on W2K and see it. Shrir saw it. I'll run through some more 
tests.
Status: NEW → ASSIGNED
(Assignee)

Updated

17 years ago
Blocks: 32668
(Assignee)

Comment 34

17 years ago
Patch checked in. Marking FIXED.

new revision: 1.207; previous revision: 1.206
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 35

17 years ago
still seeing this problem. Confirmed with Peter...reopening..
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 36

17 years ago
Reassigining to saari and moving to m0.9.1
Assignee: peterlubczynski → saari
Status: REOPENED → NEW
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 37

17 years ago
You *still* see this?

Comment 38

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

Comment 39

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

Comment 40

17 years ago
*** Bug 60102 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 41

17 years ago
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?
Blocks: 60102
(Assignee)

Comment 42

17 years ago
Rod,

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

Comment 43

17 years ago
*** Bug 60102 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 44

17 years ago
Takeing over.

Note: This is not a bug in MFCEmbemd or viewer. Backspace works there and should 
work for embedding.
Assignee: saari → peterlubczynski
Priority: P3 → P1

Comment 45

17 years ago
no reason to be ns confidential. fixing
Group: netscapeconfidential?

Comment 46

17 years ago
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

17 years ago
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?
(Assignee)

Comment 48

17 years ago

*** This bug has been marked as a duplicate of 60102 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 49

17 years ago
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

17 years ago
verified dups
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.