Bugzilla – Full Text Bug Listing
| Summary: | Paste in bultin-browser goes to address field instead of form input field | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Robin Rosenberg <robin.rosenberg> | ||||||
| Component: | User Assistance | Assignee: | Chris Goldthorpe <cgold> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | ccc, cgold, grant_gayed, kaloyan, makandre, pwebster | ||||||
| Version: | 3.4 | ||||||||
| Target Milestone: | 3.5 M4 | ||||||||
| Hardware: | Other | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Robin Rosenberg
The Platform actually provides the browser via a SWT widget. I don't see the behaviour you're describing, but I do see copy/cut/paste/selectAll no longer working in the Internal Web Browser view in 3.4. I've investigated this and found that it's not a Browser problem (these keys work well in a stand-alone Browser case), but there were Browser changes made during 3.4 that have resulted in the eclipse workbench mistakenly eating these keys rather than leaving them for Mozilla to handle. Taking ownership for now while determining how to handle this. The Browser could fix this by providing new copy/cut/paste/selectAll() api for the workbench to invoke, but at this point I'm not sure if this is the thing to do. I believe this will be fixed by the fix for bug 243210 (I know the Browser != AWT but I think the cause was the same). Can you try 3.4.1 build http://download.eclipse.org/eclipse/downloads/drops/M20080827-2000/index.php and follow up here whether this helps? Unfortunately there is no change. Paste in any field goes to the address bar and cut doesn't work in any form field. According to the build logs the build for the platform I'm using (linux x86 gtk) is broken in a test called Browser9. The Browser9 test failure is not a problem. To investigate this I'll have to reproduce it. Can you give me complete steps, including what to download, etc? I live quite far below the level of web apps. A few more version numbers, not sure if they are relevant. libgtk+1.2-1.2.10-48mdv2008.1 libgtkmm2.4_1-2.12.7-1mdv2008.1 libgtk+2.0_0-devel-2.12.9-2mdv2008.1 libgtk+-x11-2.0_0-2.12.9-2mdv2008.1 libgtk-linux-fb-2.0_0-2.4.14-6mdk gtk+2.0-2.12.9-2mdv2008.1 libgtkhtml2_0-2.11.1-2mdv2008.1 libgtk+2.0_0-2.12.9-2mdv2008.1 1. Download http://download.eclipse.org/eclipse/downloads/drops/M20080827-2000/download.php?dropFile=eclipse-SDK-M20080827-2000-linux-gtk.tar.gz 2. Extract the archive into a new folder 2. Start eclipse and give it a new workspace 3. Create a new java project 'X' in the workspace 4. Create a new file x.html in the new project So now we have a web browser inside eclipse 6. Change the url in the web browsers address bar to some page that has a form, i.e. http://google.com 7. Get some text into the clipboard (copy this line) 8. Plance the cursor in the google input form field 9. Either using Ctrl or Edit/Paste The pasted text appears in the address bar, not the input field Created attachment 111344 [details]
Screenshot
I see, so it happens specifically when the Browser is opened as an editor, not as a view. I see this happen on win32 as well. TextAction.paste() is setting the text on the Combo, which seems wrong. I'm not sure if this is UA or UI, so trying UI first. Assigning to UI for comment. Right, so org.eclipse.ui.internal.browser.TextAction is only dealing with the combo and org.eclipse.ui.internal.browser.WebBrowserEditorActionBarContributor.setActiveEditor(IEditorPart) is calling the action code to provide CUT, COPY, and PASTE for that specific web editor. If the editor is going to provide a specific cut, copy, and paste, then like org.eclipse.ui.actions.TextActionHandler it has to delegate to the in-focus component in a way that allows it to work, deciding between the Combo and the browser widget (my example, TextActionHandler only deals with multiple Text widgets in one editor). What if you simply remove these actions (delete them completely)? When I did that, the native behaviour for Combo and for the Browser widget seemed to do what I want. The only behaviour that was a little odd was select all (it worked on each widget and you needed to depend on colour to determine which one would be copied to the clipboard). PW Ping Chris for reply to comment #10 Based on Paul's analysis it looks like you should reassign this bug back to UA and I'll try that solution to see how it works. *** Bug 253081 has been marked as a duplicate of this bug. *** Created attachment 116835 [details]
Patch
This removes the override of the global actions for cut, copy and paste. I cannot detect any negative impact as a result of removing these.
Fixed in HEAD. Is it possible to have this patch in 3.4.2, too. June 2009 sounds really far away in the future. I'm hesitant to fix it for 3.4.2 because I have got burned in the past with bug fixes in point releases which cause regressions (Bug 252887). If this was for 3.4.1 I would probably have said yes but for 3.4.2 the PMC has asked us to only fix high severity bugs. If you can make a good case for why this is high severity I may be able get it into 3.4.2. Please, check the duplicated bug 253081. The problem with the Paste action leads to bad user experience when working with the Mylyn Task editor against a Trac repository. In the Trac use case the Task editor embeds the build-in browser. It is very often to paste things like hyperlinks, class names, etc. when writing comments in Trac. This bug could drive users back from using Mylyn Trac integration. OK you've convinced me. Are you in a position to test out this fix before I backpatch the 3.4 maintenance stream. Yes, I will apply the patch on top of 3.4.1 and will update you. I have applied the patch on top of 3.4.1. Ctrl+X/C/V work as expected. But the Edit > Cut/Copy/Paste menu actions don't work when the selection/focus is inside the browser's body. Is this behaviour expected? (In reply to comment #21) > I have applied the patch on top of 3.4.1. > Ctrl+X/C/V work as expected. But the Edit > Cut/Copy/Paste menu actions don't > work when the selection/focus is inside the browser's body. Is this behaviour > expected? yes. The same limitation applies to the Browser View as well. Unless you provide a handler to eclipse for that part, Edit>Cut/Copy/Paste will not work. Since this fix for non-SWT Text widgets is to say we're not handled at all (so the native behaviour can take over) eclipse has no way to execute copy from the menu. The solution involves the part providing a handler, and that handler being able to delegate to the focus widget (like a CCombo) or tell the browser (cut/copy/paste) which will only work if the browser provides programmatic access to that functionality. PW Then I would say that applying the patch in the 3.4.x stream is as good as in the 3.5 stream. Since there is a side effect of removing this event handler I am not too inclined to port the fix to the maintenance stream. This bug has been around for a few releases and is more of an annoyance than a serious bug which causes data loss. Given the above I think the fix does not meet the criteria for inclusion in Eclipse 3.4.2. |