Closed Bug 60712 Opened 24 years ago Closed 23 years ago

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

Categories

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

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 60102
Milestone:
mozilla0.9.1

People

(Reporter: kiwi, Assigned: peterlubczynski-bugs)

References

(
URL
)

Details

Attachments

(2 files)

this patch fixes the problem (patch is for branch)
5.23 KB, patch
Details | Diff | Splinter Review
first try at a fix for this using #ifndef XP_WIN
1.83 KB, patch
Details | Diff | Splinter Review 
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
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
Closed: 24 years ago
Resolution: --- → DUPLICATE
But this bug also happens on windows (1211).
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 → ---
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
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
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 → ---
And this is why I want to unify plugin event handling.

Is this something we need for 6.01?
It is not on this list http://slip/projects/seamonkey/main-rel-list.html
How hard is the task?
Actually, it looks easier than I thought, I'm doing a build with a potential fix
right now.
Can the link I just posted be viewed from outside? If it can, we should probably 
turn this bug report into 'confidential'.
changing status: confidential
Group: netscapeconfidential?
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
Blocks: 65204
are we not fixing this on the branch ?
Isn't this already check-in/fixed?
Keywords: verifyme
I thought it was checked in...
moving to m0.9
Target Milestone: --- → mozilla0.9
I think this is checked-in on the trunk too. Marking FIXED to trigger verify.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Whiteboard: [branch accept]
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 → ---
added test url...
URL: http://slip/shrir/flashedit.html
Chris, can you migrate your changes from the branch to the trunk?
I could swear this is in the trunk, but I'll double check as soon as my windows
build is done.
okay, I suck, looks like I never did get this on the trunk
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?
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.. :(
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
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.
Works on linux ..this is windows and windows only ! :-)
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
Peter, why dontcah put in some comments on why WIN doesn't want that code?!?
[s]r=attinasi
r=saari if it works for you, but I'm a little concerned that I still don't see
the bug on Win2k...
That's strange. I'm on W2K and see it. Shrir saw it. I'll run through some more 
tests.
Status: NEW → ASSIGNED
Blocks: 32668
Patch checked in. Marking FIXED.

new revision: 1.207; previous revision: 1.206
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
still seeing this problem. Confirmed with Peter...reopening..
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Reassigining to saari and moving to m0.9.1
Assignee: peterlubczynski → saari
Status: REOPENED → NEW
Target Milestone: mozilla0.9 → mozilla0.9.1
You *still* see this?
yes on today's windows (0412) going to www.emailtrack.com and typing something 
in the flash textfield shows this problem.
*** Bug 75972 has been marked as a duplicate of this bug. ***
*** Bug 60102 has been marked as a duplicate of this bug. ***
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
Rod,

How did you solve this problem for text boxes like the address bar?
*** Bug 60102 has been marked as a duplicate of this bug. ***
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
no reason to be ns confidential. fixing
Group: netscapeconfidential?
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.
URL: http://slip/shrir/flashedit.html → http://www.emailtrack.com
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?

*** This bug has been marked as a duplicate of 60102 ***
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
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;
+    }
verified dups
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: