Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 294635

Summary: [Browser] browser widget prevents part activation
Product: [RT] RAP Reporter: Ralf Sternberg <rsternberg>
Component: RWTAssignee: Project Inbox <rap-inbox>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: P3    
Version: 1.3   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Proposed patch none

Description Ralf Sternberg CLA 2009-11-09 11:50:20 EST 
It seems that the browser widget prevents part activation. You can reproduce this in the examples demo using the fancy design (which decorates active parts with a green border). Click into the right view part, the part is not activated.
Comment 1 Ivan Furnadjiev CLA 2009-11-11 10:27:32 EST 
Browser widget is based on IFrame. The IFrame consumes all the mouse (DOM) events and the parent document (RAP application) is completely blind about these events. Thus, when you click on the Browser widget, RAP application (qooxdoo framework) is not informed about this event and the Browser does not gain the focus - part is not activated. Due to "cross-scripting security policy" it is not possible to attach a mouse listener to the IFrame document, if its origin is different than the parent document. To my knowledge, in this case we can't do anything about it - Browser (IFrame) is a "black" hole for all DOM events.
Comment 2 Ivan Furnadjiev CLA 2009-11-11 14:22:06 EST 
Created attachment 151962 [details]
Proposed patch

Here is one "impossible" implementation. It is based on qooxdoo IFrame blocker node. The blocker node is used for Browser mouse down event handling. This implementation has only one "disadvantage" - it's possible to act with Browser document (activate hyperlink for example)  if Browser widget is focused.
Comment 3 Ivan Furnadjiev CLA 2009-11-12 15:58:06 EST 
We decided to close this bug as WONTFIX. It is better to have Browser widget (Browser document hyperlink for example) responsive to first click instead of fixing the issue with the proposed patch that uses first click for widget focusing.