Community
Participate
Working Groups
The initial release of the SWT Browser widget (SWT 3.0 release) is designed to provide a portable API sufficient for basic HTML rendering and browsing. As such, it does not expose the (large!) DOM API as implemented by som native Browsers. DOM API support should be investigated post 3.0. Major browsers (IE, Mozilla, Safari) expose the DOM to HTML developers through the javascript interface. Some points: - DOM support adds a large set of java interfaces/classes to the API. Should this DOM extension live inside SWT or in a separate project? - Compatibility. Most Browsers (IE/Mozilla/Safari) have a good support for the unofficial javascript / dom level 0 model. Mozilla is deemed to have a 'fairly' good support for DOM level 2. IE is reported to require workarounds to 'implement' the DOM level 2 events. Certain other browsers don't expose their DOM API to C embedders (only to javascript). Should we focus on providing support for one browser (Mozilla?) only? Two (IE and Mozilla?) ? - Support. DOM support evolves with native browsers. The W3C is now working on the DOM level 3. If we support the DOM on a set of browsers (different versions of Mozilla and IE for example) and identify bugs on different platforms/versions, should these bugs worked around in our java bridge or should the application code responsible for compatibility issues the same way javascript/HTML developers need to be aware of platform and browser incompatibilities. - support for DOM could be added by providing a subclass of the portable Browser widget with a getDocument method. - which subsets of the DOM should be supported? The DOM API comprises core/events and many other sets of API. Are these APIs going to conflict with existing SWT APIs in some way (event API?)
*** Bug 58360 has been marked as a duplicate of this bug. ***
It would be to get access to the DOM element that caused a link’s activation. In my context I would like to get to the associated attributes such as id and class and perhaps some which are not defined by HTML.
This might become much more simple when Bug 79213 (=use the Mozilla engine on all platforms) is implemented.
Yes, in fact bug 79213 is the answer for this, as there are no plans to create a Browser-independent DOM api layer. Marking report as a duplicate; anyone here that's not copied on bug 79213 should do so. *** This bug has been marked as a duplicate of 79213 ***
I do not agree that 79213 will satisfy the need enough because Browser is also part of the eSWT. Mobile platforms usually have a browser but this is rarely mozilla. I think a solution for this should be general enough to be implemented in eSWT.
I can't see how using Mozilla for SWT can have any impact on eSWT. On eSWT, you will have to write your own code for each supported platform anyway. Fixing Bug 79213 would just make things more simple for all SWT users on three platforms and make the fix for this bug much more simple. The only area of intersection is probably the power of the API. But with HTML, I guess the core DOM API will be just three methods: find an element, set an attribute, read an attribute. I'm not sure if adding special methods (and classes for each HTML element) will yield such a big return. That should satisfy the initial needs of all parties. On a different note, I think it would be better to say that this bug *depends* on Bug 79213 instead of being a duplicate.
makes sense, reopening
I do not mean that bug 79213 will not help with this on some platforms but it does not help if we have access to DOM APIs in a Mozilla specific apis in eSWT. I would like to see this report as the means to extend Browser to provide access to DOM. Anyway thanks to your comments this is reopen now.
Moving report to triage, see http://www.eclipse.org/swt/triage.php for more info about swt triage.
Support for Mozilla style browser has been dropped for 4.8. See Bug 518446 Hence, scope of this enhancement is now limited to IE and Webkit.
Browser integration is already terrible experience so any more advanced features should be implemented using JS and browser functions.
