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

Bug 57477

Summary:	[browser] Investigate support for DOM API (post 3.0)
Product:	[Eclipse Project] Platform	Reporter:	Christophe Cornu <christophe.cornu+eclipse>
Component:	SWT	Assignee:	Platform-SWT-Inbox <platform-swt-inbox>
Status:	CLOSED FIXED	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	akurtakov, bpasero, capelli, carolynmacleod4, chrriis, daniel_megert, david_williams, ed.burnette, gorkem.ercan, jobi, Matthew_Hatem, mfaraj, micmax, mikehoeffner, niraj.modi, ovidr, schlamp, thatnitind, wayne, wuhaijie
Version:	3.0	Keywords:	triaged
Target Milestone:	---
Hardware:	PC
OS:	All
Whiteboard:

Description Christophe Cornu

2004-04-05 12:52:18 EDT

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?)

Comment 1 Christophe Cornu

2004-04-13 16:56:21 EDT

*** Bug 58360 has been marked as a duplicate of this bug. ***

Comment 2 Henrich Kraemer

2004-11-17 13:35:26 EST

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.

Comment 3 Aaron Digulla

2006-11-10 09:36:39 EST

This might become much more simple when Bug 79213 (=use the Mozilla engine on all platforms) is implemented.

Comment 4 Grant Gayed

2006-11-10 09:53:58 EST

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 ***

Comment 5 Gorkem Ercan

2006-11-15 17:07:36 EST

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.

Comment 6 Aaron Digulla

2006-11-16 04:01:53 EST

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.

Comment 7 Grant Gayed

2006-11-16 09:30:23 EST

makes sense, reopening

Comment 8 Gorkem Ercan

2006-11-16 10:06:02 EST

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.

Comment 9 Grant Gayed

2009-08-27 15:02:52 EDT

Moving report to triage, see http://www.eclipse.org/swt/triage.php
for more info about swt triage.

Comment 10 Niraj Modi

2017-07-13 06:52:04 EDT

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.

Comment 11 Alexander Kurtakov

2022-02-23 12:53:15 EST

Browser integration is already terrible experience so any more advanced features should be implemented using JS and browser functions.