[gwt-contrib] Re: RPC HashSet HashMap deserialization bug/limitation
Cycles are handled properly - the problem comes with calling methods on partially formed objects during deserialization. It doesn't matter how you implement equals or hashCode if those methods are called before any data is deserialized onto your objects. You just need a suitable object graph for this to show itself. On Fri, Apr 17, 2009 at 1:01 AM, Miroslav Pokorny miroslav.poko...@gmail.com wrote: If one were to serialize the entries rather than recreating the map via put alot of other things would need to be changed. For one the calculation of hashcodes in emulated jre would need to match those on the server otherwise look ups by string in a hashmap sent over the wire would never work. Which jre would one base calculation a on - I say this because wire formsts can and do chsnge - which is why serialUID exists etc . We don't need to introduce that into gwt serialization and make things more complicated and bloated. Unfornately javascript is not the fastest ultimately to improve serialization performance in javascript one needs to to sensible things like tailoring what gets marshalled. The browser has limits and one needs to do the hard work and change accordingly... Um peetty sure gwt handles cycles properly without problems - perhaps your objects in the map / set are changing in some way or your equals/ hashcode is broken. Regarding your problem gave you confirmed serializi g the same instances to bytes and back in real java??? Hth. On 17/04/2009, at 2:04 AM, Paul Robinson ukcue...@gmail.com wrote: I've found what I think is a bug in the RPC deserialization code for handling HashSet and HashMap in GWT 1.5.3 (though I believe it applies to trunk as well). The symptoms I had initially were that I sent an object tree to the client, and a HashSet that had 2 elements on the server only had 1 by the time it got to the client. When deserializing, an instance is created, stored in a map so repeated references can use the same instance, and then the fields of the instance are deserialized. If you have an object tree where A contains a reference to something that has a reference to B, and B contains something that has a reference to a HashSet that contains both A and B, then when deserializing the set, both A and B may only be partially constructed (depending on the order in which the fields and instances are deserialized). This would be ok except that HashSet deserialization is done by Collection_CustomFieldSerializerBase which ends up calling HashSet.add(Object) to reconstitute the set, and that in turn calls equals() and hashCode() on the object being added in. This gives rise to two possible errors: (1) Depending on how the equals() method on A and B is implemented and on the order in which the fields are deserialized, A.equals(B) may be true at the time that A and B are added to the set. However, A.equals(B) could later evaluate to false once the whole deserialization has completed. This would mean the set is missing one of the objects, since HashSet.add() thinks they are the same. (2) When adding an object to a HashSet or HashMap during deserialization, if the object being added is partially constructed, then the hashCode() method may return a different value as it is added to the set from what it does when deserialization is complete. This could lead to occasional data-driven bugs that are very hard to track down. Have I got this right? Is this a bug (or perhaps a known limitation)? In my case, I have been able to work around this by creating a custom field serializer that chooses the order in which fields are written out so that partially constructed objects will still behave properly in a HashSet/HashMap. Paul --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Google Plugin for Eclipse
Is the Google Eclipse Plugin not a Google Code OSS project? -- Arthur Kalmenson On Thu, Apr 16, 2009 at 11:18 PM, Alex Rudnick a...@google.com wrote: Gary, Here is fine (alternatively, on the Google-Web-Toolkit group). What issues and questions have you got? On Thu, Apr 16, 2009 at 8:20 PM, Gary Miller miller.ga...@gmail.com wrote: Where is the correct place to post issues and questions for Google Plugin for Eclipse? -- Alex Rudnick swe, gwt, atl --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Google Plugin for Eclipse
http://code.google.com/eclipse/docs/faq.html#source It is not (yet). Although I've wondered why there isn't an empty shell of a project on Google Code, just for the Issue Tracker if nothing else. On Fri, Apr 17, 2009 at 8:20 AM, Arthur Kalmenson arthur.k...@gmail.com wrote: Is the Google Eclipse Plugin not a Google Code OSS project? -- Arthur Kalmenson On Thu, Apr 16, 2009 at 11:18 PM, Alex Rudnick a...@google.com wrote: Gary, Here is fine (alternatively, on the Google-Web-Toolkit group). What issues and questions have you got? On Thu, Apr 16, 2009 at 8:20 PM, Gary Miller miller.ga...@gmail.com wrote: Where is the correct place to post issues and questions for Google Plugin for Eclipse? -- Alex Rudnick swe, gwt, atl --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on WAR_Design_1_6 in google-web-toolkit
Comment by freecomputerbooks: I am sorry, but I didn't what JDK version required for GWT 1.6? I know JDK 1.5 is required for GWT 1.5x. Thanks! For more information: http://code.google.com/p/google-web-toolkit/wiki/WAR_Design_1_6 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5255 - Edited wiki page through web user interface.
Author: j...@google.com Date: Fri Apr 17 07:40:37 2009 New Revision: 5255 Modified: wiki/IE8Support.wiki Log: Edited wiki page through web user interface. Modified: wiki/IE8Support.wiki == --- wiki/IE8Support.wiki(original) +++ wiki/IE8Support.wikiFri Apr 17 07:40:37 2009 @@ -16,14 +16,10 @@ * CoreWithUserAgent * ImageSrcIE6 * ClippedImage - * Need to turn off the IE6 hacks for IE7 (they're no longer necessary). * Focus * FormPanel * Popup - * Need to turn off the IE6 hacks for IE7 (they're no longer necessary). - * Standard PopupImpl works on IE8, but you can still open the select box. * RichTextArea - * All kinds of screwed up in IE8 standards mode. * TextBox * Tree --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on WAR_Design_1_6 in google-web-toolkit
Comment by j...@deepthoughtgames.com: JDK 1.5+ For more information: http://code.google.com/p/google-web-toolkit/wiki/WAR_Design_1_6 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Code review: Refactoring the JReferenceType hierarchy
One question: I see a change to how enums are created in
GenerateJavaAST. What's going on there? I see code being deleted but
no associated add.
Otherwise, LVGTM. I've been wanting this type hierarchy for a while
just for logical cleanliness. I hadn't thought about the memory and
speed implications, but those are excellent as well.
Comments:
JReferenceType has a commented-out getMethods() in the version I looked at.
Logically, a little bit more could go down into JDeclaredType. They seem
like good todos to mark, because ideally these questions wouldn't be asked
on a general reference type. This issue becomes more important the more
we expand the JReferenceType hierarchy.
- superclass: arrays and null don't really have a superclass, so it's
tricky to ask for it. Allowin callers to do so seems like an
invitation for bugs,
e.g. asking for the superclass of String[] when what was intended was asking
for the superclass of String.
- hasClinit: this question is only asked for field references, and a
field always has a real enclosing class. The one exception I can
think of the length field of an array; if that's the issue, maybe we should
think about encoding array.length a different way, anyway.
Methods like removeMethod(int) are an improvement over directly accessing the
list, but it looks fragile to me due to how careful the code has to be
with the index
passed into it. It would be a little simpler and safer to have a
method like removeAllMethodsSuchThat(PredicateJMethod). For
example, instead of this:
for (int i = 1; i type.getMethods().size(); ++i) {
JMethod method = type.getMethods().get(i);
// all other interface methods are instance and abstract
if (!isInstantiated || !methodIsReferenced(method)) {
type.removeMethod(i);
didChange = true;
--i;
}
}
we could write this:
didChange |= type.removeAllMethodsSuchThat(new PredicateJMethod() {
public boolean apply(JMethod method) {
// all other interface methods are instance and abstract
return !isInstantiated || !methodIsReferenced(method);
}
}
Just a thought. Sometimes this idiom can push out just a little
further the complexity threshold where brains start melting.
Lex
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT 1.6 #5110 SVN: MouseWheel event not working on Firefox3
Thanks for pointing this out. It's captured in issue 2902, and I'll try to
get a fix in Real Soon Now.
On Sat, Apr 4, 2009 at 12:37 PM, aris ari09845...@gmail.com wrote:
Hello
I just found that the mousewheel event is working in all browsers but
not in Firefox 3 (3.0.7)
using a simple new GWT appl with:
public void onModuleLoad()
{
HTML sp = new HTML(Hello World);
RootPanel.get().add(sp);
sp.addMouseWheelHandler(new MouseWheelHandler()
{
public void onMouseWheel(MouseWheelEvent event)
{
Window.setTitle(A: +new Date().getTime());
}
});
}
it doesn't work...
maybe it is using mousewheel instead of DOMMouseScroll (?)
TIA
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: review request: clean up the RPC compile-time noise
On Thu, Apr 16, 2009 at 7:02 PM, Freeland Abbott fabb...@google.com wrote: On Thu, Apr 16, 2009 at 5:27 PM, Lex Spoon sp...@google.com wrote: I wouldn't expect TypeExposureComputer to need to report any problems. Did you run any any cases where it should? Barring an argument to the Not directly, no, but it's needed for pass-through to e.g. STOB.shouldConsiderFieldsForSerialization by way of computeIndirectExposureCauses(). In that case it seems better to pass in an empty problem report, as is done for similar methods that expect a logger. Are we assured that the TIEC won't, in its wanderings back through STOB, visit anything that hasn't already been touched? (Bearing in mind that visitation now implies creating TIC which implies short circuiting revisitation, so we only get one shot to collect problems uncovered) If we are, then yes, instead of passing through I can create and discard new ProblemReports. It only calls static methods of STOB, and doesn't (or at least shouldn't) even have an instance of STOB. Thus, it can't affect the set of TICs directly. The overall pattern is that STOB creates a TEC to do some analysis for it. It then queries that TEC for the results of those analysis whenever it needs. Maybe those analysis results should be logged, but nobody has worked out exactly how to do that. That's why it previously passed TreeLogger.NULL; the analogous thing with your patch would be a new ProblemReport whose data is ignored. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: review request: clean up the RPC compile-time noise
Right, and I also checked that in fact the errors ought to have been caught anyway. Validating the tests, will submit (as I think you okayed) when they're proven still unchanged. On Fri, Apr 17, 2009 at 2:50 PM, Lex Spoon sp...@google.com wrote: On Thu, Apr 16, 2009 at 7:02 PM, Freeland Abbott fabb...@google.com wrote: On Thu, Apr 16, 2009 at 5:27 PM, Lex Spoon sp...@google.com wrote: I wouldn't expect TypeExposureComputer to need to report any problems. Did you run any any cases where it should? Barring an argument to the Not directly, no, but it's needed for pass-through to e.g. STOB.shouldConsiderFieldsForSerialization by way of computeIndirectExposureCauses(). In that case it seems better to pass in an empty problem report, as is done for similar methods that expect a logger. Are we assured that the TIEC won't, in its wanderings back through STOB, visit anything that hasn't already been touched? (Bearing in mind that visitation now implies creating TIC which implies short circuiting revisitation, so we only get one shot to collect problems uncovered) If we are, then yes, instead of passing through I can create and discard new ProblemReports. It only calls static methods of STOB, and doesn't (or at least shouldn't) even have an instance of STOB. Thus, it can't affect the set of TICs directly. The overall pattern is that STOB creates a TEC to do some analysis for it. It then queries that TEC for the results of those analysis whenever it needs. Maybe those analysis results should be logged, but nobody has worked out exactly how to do that. That's why it previously passed TreeLogger.NULL; the analogous thing with your patch would be a new ProblemReport whose data is ignored. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: review request: clean up the RPC compile-time noise
On Fri, Apr 17, 2009 at 12:02 PM, Freeland Abbott fabb...@google.com wrote: Right, and I also checked that in fact the errors ought to have been caught anyway. Validating the tests, will submit (as I think you okayed) when they're proven still unchanged. Yes, please go ahead! -Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Extends ClassInitTest (the mockability test) to cover com.google.gwt.dom.client
On 2009/04/16 21:42:02, jlabanca wrote: LGTM Holding off on this. The JSOs are full of final methods, and so not mockable. Need to think about how to get interfaces involved, and if it's worth the bother. http://gwt-code-reviews.appspot.com/20803 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Fwd: DateTimeFormat parsing patch
LGTM. Thanks, Shanjian! Committed to the trunk at r5257. On Fri, Apr 17, 2009 at 2:19 PM, Shanjian Li shanjia...@gmail.com wrote: This is a complete patch to address a bug in DateTimeFormat parsing code. Zero should be treated as invalid input for month and day-of-month value. shanjian -- Alex Rudnick swe, gwt, atl --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r5257 - Fixes a bug where DateTimeFormat would accept 0 as a valid month or day. Also
Author: a...@google.com
Date: Fri Apr 17 14:54:39 2009
New Revision: 5257
Modified:
trunk/user/src/com/google/gwt/i18n/client/DateTimeFormat.java
trunk/user/test/com/google/gwt/i18n/client/DateTimeParse_en_Test.java
Log:
Fixes a bug where DateTimeFormat would accept 0 as a valid month or day.
Also
adds a test to demonstrate the fix.
patch by: shanjianli
review by: ajr
Modified: trunk/user/src/com/google/gwt/i18n/client/DateTimeFormat.java
==
--- trunk/user/src/com/google/gwt/i18n/client/DateTimeFormat.java
(original)
+++ trunk/user/src/com/google/gwt/i18n/client/DateTimeFormat.java Fri Apr
17 14:54:39 2009
@@ -1705,6 +1705,9 @@
case 'y': // 'y' - YEAR
return subParseYear(text, pos, start, value, part, cal);
case 'd': // 'd' - DATE
+if (value = 0) {
+ return false;
+}
cal.setDayOfMonth(value);
return true;
case 'S': // 'S' - FRACTIONAL_SECOND
@@ -1823,10 +1826,11 @@
}
cal.setMonth(value);
return true;
-} else {
+} else if (value 0) {
cal.setMonth(value - 1);
return true;
}
+return false;
}
/**
Modified:
trunk/user/test/com/google/gwt/i18n/client/DateTimeParse_en_Test.java
==
--- trunk/user/test/com/google/gwt/i18n/client/DateTimeParse_en_Test.java
(original)
+++ trunk/user/test/com/google/gwt/i18n/client/DateTimeParse_en_Test.java
Fri Apr 17 14:54:39 2009
@@ -638,4 +638,25 @@
assertTrue(date.getDate() == 02);
}
+ public void testInvalidDayAndMonth() {
+DateTimeFormat fmt = DateTimeFormat.getFormat(MM/dd/);
+try {
+ fmt.parseStrict(00/22/1999);
+ fail(Should have thrown an exception on failure to parse);
+} catch (IllegalArgumentException e) {
+ // Success
+}
+try {
+ fmt.parseStrict(01/00/1999);
+ fail(Should have thrown an exception on failure to parse);
+} catch (IllegalArgumentException e) {
+ // Success
+}
+try {
+ fmt.parseStrict(01/22/1999);
+ // success
+} catch (IllegalArgumentException e) {
+ fail(Should succeed to parse);
+}
+ }
}
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Add getElementsByTagName to DOM class patch
getElementsByTagName missing from DOM class.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
diff --git a/user/src/com/google/gwt/user/client/DOM.java b/user/src/com/google/gwt/user/client/DOM.java
index 03721b8..ddbac26 100644
--- a/user/src/com/google/gwt/user/client/DOM.java
+++ b/user/src/com/google/gwt/user/client/DOM.java
@@ -751,6 +751,17 @@ public class DOM {
}
/**
+ * Gets all the elements with the given tag name within the entire
+ * document.
+ *
+ * @param tagName the HTML tag name whose associated elements are to be retrieved
+ * @return the associated elements, or codenull/code if none is found
+ */
+ public static NodeListElement getElementsByTagName(String tagName) {
+return Document.get().getElementsByTagName(tagName).cast();
+ }
+
+ /**
* Gets any named property from an element, as a string.
*
* @param elem the element whose property is to be retrieved
[gwt-contrib] Re: Add getElementsByTagName to DOM class patch
Did you look at the Document/Element classes? It's there. I think of the DOM classes as semi-deprecated, in that many of the methods are now subsumed by overlay types. -Ray On Fri, Apr 17, 2009 at 4:54 PM, Vitali Lovich vlov...@gmail.com wrote: getElementsByTagName missing from DOM class. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Add getElementsByTagName to DOM class patch
Yes I did (since the DOM one just wraps the Document one). It seems like the DOM methods wrap the Document ones, so it was just surprising it wasn't there. On Fri, Apr 17, 2009 at 7:58 PM, Ray Cromwell cromwell...@gmail.com wrote: Did you look at the Document/Element classes? It's there. I think of the DOM classes as semi-deprecated, in that many of the methods are now subsumed by overlay types. -Ray On Fri, Apr 17, 2009 at 4:54 PM, Vitali Lovich vlov...@gmail.com wrote: getElementsByTagName missing from DOM class. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Eclipse Plugin and OSX woes
Hey Matt, Unfortunately, it's not currently possible to specify arguments to the JVM that runs the GWT compile. We're aware of the demand for this feature though, so expect it in a future release. As an absolute workaround, could you rename your java binary and create a shell script in its place that launches the real java binary with whichever args you want (prepended to the args given to the shell script)? jason On Fri, Apr 17, 2009 at 2:34 PM, Matt Mastracci matt...@mastracci.com wrote: I'm running into the same JVM crash under Eclipse that I was running into from Ant a few weeks ago (http://grack.com/blog/2009/04/14/gwt-16-crashes-and-a-fix/ ) while trying to deploy a test AppEngine+GWT project. The output from the compiler is pretty much: Compiling module ... Invalid memory access of location rip=01160767 Any ideas where the Eclipse Plugin gets the JVM and the JVM arguments to run to GWT portion of the compile? I tried adding the JIT overrides to the workspace JRE default JVM properties, but those don't seem to get picked up. -XX:CompileCommand=exclude,org/eclipse/core/internal/dtree/ DataTreeNode,forwardDeltaWith -XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/lookup/ ParameterizedTypeBinding,init -XX:CompileCommand=exclude,org/eclipse/jdt/internal/compiler/lookup/ ParameterizedMethodBinding,init The only argument I can see in the process list is -Xmx512m. Thoughts/ideas? Thanks, Matt. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Patch to add getElementsByClassName support
Provide some tests and make sure it works on all officially supported
browsers even if the implementation is suboptimal. There are many js
libs out there so it's not hard to find the best way to do it fir the
various browsers...
On 18/04/2009, at 12:39 PM, Vitali Lovich vlov...@gmail.com wrote:
Just my first attempt at adding some initial support for
getElementsByClassName. This is by no means tested or
Newer browsers support getElementsByClassName. This is my attempt
at a patch.
Caveats:
There's a bug in that quirks mode doesn't behave properly (I don't
know how to detect it in the deferred binding) for IE Firefox2
earlier. According to the HTML5 spec, it's supposed to be case
insensitive in quirks mode. However, this bug behaves the exact
same way as all the javascript wrappers do (since I based the XPath
RegExp code paths roughly around the implementations floating out
there).
I'm also not sure if I added the support correctly for Firefox.
getElementsByClassName only came in with FF3 requires the xpath
workaround for FF2 earlier (I believe I read xpath was introduced
with FF 1.5). I placed the xpath code in DOMImplMozillaOld for now
(not sure whether or not gecko1_8 represents FF2).
There's also no mention of the versions of Safari Opera that are
supported by GWT, so they're defaulting to using the native version
(which will not work if they don't provide it).
Safari in particular got it with version 3.1. if earlier versions are
supported, it's not too much work. Simply grab the expression built
in the FF xpath pass it to document._getElementsByXPath(query,
parent) for Safari versions that have xpath (not sure which those
are). Not sure how to distinguish Safari pre3.1 post3.1 in deferred
binding.
Opera got it with 9.5. Not sure when xPath support got into Opera
(should be a straightfoward copy of the mozilla code). Not sure how
to distinguish the two in the deferred binding.
Feedback would be appreciated.
Should this go as an enhancement request in the issue tracker?
diff --git a/user/src/com/google/gwt/dom/client/DOMImpl.java b/user/
src/com/google/gwt/dom/client/DOMImpl.java index 1d7e39b..581764b
100644 --- a/user/src/com/google/gwt/dom/client/DOMImpl.java +++ b/
user/src/com/google/gwt/dom/client/DOMImpl.java @@ -176,6 +176,8 @@
abstract class DOMImpl { return 0; }-*/; + public abstract NodeList
getElementsByClassName(Element parent, String className); + public
native Element getFirstChildElement(Element elem) /*-{ var child =
elem.firstChild; while (child child.nodeType != 1) diff --git a/
user/src/com/google/gwt/dom/client/DOMImplIE6.java b/user/src/com/
google/gwt/dom/client/DOMImplIE6.java index 04c205a..8c24a6c 100644
--- a/user/src/com/google/gwt/dom/client/DOMImplIE6.java +++ b/user/
src/com/google/gwt/dom/client/DOMImplIE6.java @@ -15,6 +15,8 @@ */
package com.google.gwt.dom.client; +import
com.google.gwt.core.client.JsArray; + /** * Internet Explorer 6
implementation of * {...@link com.google.gwt.user.client.impl.DOMImpl}.
@@ -184,6 +186,31 @@ class DOMImplIE6 extends DOMImpl { } @Override
+ public NodeList getElementsByClassName(Element parent, String
className) { + // TODO: detect quirks mode so that the regexps do a
case insensitive match as per the + // spec. when quirks mode
detected, pass i as the flags parameter + return
getElementsByClassName(parent, className.split( ), ).cast(); + }
+ + private native JsArray getElementsByClassName(Element parent,
String [] classes, String flags) /*-{ + var i, j, e, c, elements =
parent.all || parent.getElementsByTagName(*); + var regexps = [],
result = []; + for (i = classes.length - 1; i = 0; i--) { + c =
classes[i].replace(/^\s+|\s+$/g, ); + if (c.length) +
regexps.push(new RegExp(new Array((?:^|\\s), c, (?:\\s|
$)).join(), flags); + } + if (regexps.length) { + for (i = 0, c =
elements.length; i c; i++) { + e = elements[i]; + for (j =
regexps.length - 1; j = 0 regexps[j].test(e); j--) {} + j == -1
result.push(e); + } + } + return result; + }-*/; + + @Override
public native String getInnerText(Element elem) /*-{ return
elem.innerText; }-*/; diff --git a/user/src/com/google/gwt/dom/
client/DOMImplMozillaOld.java b/user/src/com/google/gwt/dom/client/
DOMImplMozillaOld.java index ecf52fb..5fd7312 100644 --- a/user/src/
com/google/gwt/dom/client/DOMImplMozillaOld.java +++ b/user/src/com/
google/gwt/dom/client/DOMImplMozillaOld.java @@ -15,6 +15,8 @@ */
package com.google.gwt.dom.client; +import
com.google.gwt.core.client.JsArray; + /** * DOM implementation
differences for older version of Mozilla (mostly the * hosted mode
browser on linux). The main difference is due to changes in @@
-114,4 +116,23 @@ package com.google.gwt.dom.client; return top +
viewport.scrollTop; }-*/; + + @Override + public NodeList
getElementsByClassName(Element parent, String
