Closed Bug 611826 Opened 9 years ago Closed 7 years ago
[OOPP] [adbe 2746681] Flash crashes when pasting text into Spark Text
Area control in firefox via CTRL+V
Method: 1. nav FF3.6.x/4.0.x using a spark textarea with tlf. For example: http://help.adobe.com/en_US/flex/using/WS02f7d8d4857b1677-165a04e1126951a2d98-7fd3.html 2. click "View Running Example" button in "Creating a TextArea control" field or "Using TLF with the TextArea control" field 3. Copy any text from a firefox window (even the URL from the navigation bar) and paste it into the textarea with Ctrl+V Result: The flash player hangs and totally crashes Expected: Should paste the text into the textarea Workaround: 1. This issue only happens in Firefox with Windows Platform 2. It works fine in IE, Mac and Linux platform. 3. Copy the text from plain editor(Notepad) and then paste it into the textarea with Ctrl+V, it seems to have no problem.
I can confirm this using Build http://hg.mozilla.org/mozilla-central/rev/35dfd6a0ace7 on WinXP with Flash 10.2.161.23. The Crash Pair is: bp-164ad601-09d3-4fed-87ea-c697b2101113 [@ hang | KiFastSystemCallRet ] bp-a5bdef69-7cfb-4a36-b475-b7a642101113 [@ hang | mozilla::plugins::PPluginInstanceParent::CallNPP_HandleEvent(mozilla::plugins::NPRemoteEvent const&, short*) ] what lead to Bug 540094. The Crashs happen when the Seconds defined in dom.ipc.plugins.timeoutSecs run off. Setting dom.ipc.plugins.enabled;false helps.
Component: Extension Compatibility → Plug-ins
Product: Firefox → Core
QA Contact: extension.compatibility → plugins
Summary: [adbe 2746681] Flash crashes when pasting text into Spark TextArea control in firefox via CTRL+V → [OOPP] [adbe 2746681] Flash crashes when pasting text into Spark TextArea control in firefox via CTRL+V
Checking in on this one. We believe this is the root cause for this bug logged against Flash Player: http://bugs.adobe.com/jira/browse/SDK-28729
still able to repro: Win7 FF5.0 10,3,181,34...
Still able to produce...The priority of this must be raised... Same flex app with IE & Opera work just fine...
We should find an owner for this. Seems like it is probably easy to reproduce.
1) http://help.adobe.com/en_US/flex/using/WS02f7d8d4857b1677-165a04e1126951a2d98-7fd3.html 2) click "View Running Example" button in "Creating a TextArea control" field or "Using TLF with the TextArea control" field Using the second flash test case on that page, I'm not having much luck reproducing. Is there some trick to getting the crash? I tried a nightly, Aurora, and 5.0.
(In reply to comment #6) > 1) > http://help.adobe.com/en_US/flex/using/WS02f7d8d4857b1677- > 165a04e1126951a2d98-7fd3.html > > 2) click "View Running Example" button in "Creating a TextArea control" > field or "Using TLF with the TextArea control" field > > Using the second flash test case on that page, I'm not having much luck > reproducing. Is there some trick to getting the crash? > > I tried a nightly, Aurora, and 5.0. Jim, try copying the address bar URL and pasting it into the control.. I get it all the time! Thanks
Assignee: nobody → jmathies
(In reply to comment #8) > Created attachment 550709 [details] > copy paste hang stacks Great, so any hopeful news on this being fixed in the near future?
(In reply to comment #3) > still able to repro: Win7 FF5.0 10,3,181,34... smadayag, is there any chance you could break into flash in the plugin-container and tell me what call it's making within the winless event callback when the freeze occurs? It looks like there's some messaging going on between the sub process and the parent process related to copy paste.
from our internal bug, the call looks to be into m_dataObject->GetData. the notes state we never return from it.
(In reply to comment #11) > from our internal bug, the call looks to be into m_dataObject->GetData. the > notes state we never return from it. What type of data formats are you looking for? This is different somehow from a standard text edit in Flash, which works fine. Which isn't to say this is flash's fault, this is on our end. Normally the GetData calls are delivered to us via the clipboard manager's window in our process. For some reason those events are getting through, which means Windows is likely doing something "special" in this particular case.
"HTML Format" or "Rich Text Format"
@jim - checking in for an update and to see if there is any other info you may need on our end. thanks...
(In reply to smadayag from comment #14) > @jim - checking in for an update and to see if there is any other info you > may need on our end. thanks... The current status is such: In most cases, when a copy paste operation occurs, the child process is making a sync call to retrieve the data. This call gets passed over to the parent process (which holds the data object) and is delivered to it via a sync windowing event sent to a hidden ole clipboard window within the fx process. In this particular case, the parent is in a loop waiting on the response from the child after sending the keyboard command. Normally the clipboard windowing event would be delivered to the clipboard window and the data object would respond, but for an unknown reason the parent thread gets wrapped up in a MsgWaitForMultipleObjects call and never returns, presumably while trying to deliver the sync windowing event to the clipboard window. I do not know yet what causes this. I took a break to work on some other issues. I can circle back around on this but it will be a couple weeks before I can get back to it. The open question seems to be why is this particular copy paste operation acting differently from others. For example I have a Flash test case with a text edit in it I use for copy paste testing. Things work properly in this test case. But for some reason the newer flash rich text edit triggers different results.
The difference in the content is that the target of the Ctrl+v keyboard is a Sprite, rather than a TextField. Maybe the player is doing something in that case that's confusing things, we can look at that from our side.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.