Re: [gwt-contrib] Typed Arrays and WebGL
I'm glad you all are pushing ahead with this! Given the performance and growing browser support (IE10!), I think getting just typed arrays into GWT would be a great first-pass. Philip On Tue, Dec 27, 2011 at 7:13 PM, John Tamplin j...@google.com wrote: I haven't looked at the code yet, but one big thing is how does it handle browsers that don't support it? Traditionally core GWT only supported things that could at least be emulated everywhere, though recently some things like Canvas were added which introduced a partial support model. It would be good if WebGL used the same model. Docs and tests are necessary for going into GWT -- that doesn't mean you have to write them, but it has to get done by someone before it can go in. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Typed Arrays and WebGL
No, but typed arrays are (planned to be): http://blogs.msdn.com/b/ie/archive/2011/12/01/working-with-binary-data-using-typed-arrays.aspx Philip On Wed, Dec 28, 2011 at 5:02 PM, Patrick Julien pjul...@gmail.com wrote: Philip, are you saying WebGL is in IE10 proper? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: Indexed DB/WebStorage in GWT?
As Jeff points out, Storage is supported in GWT today. Storage is the HTML5 key/value pair datastore and has a 5mb limit (unless you are installed via the Chrome Web Store). John LaBanca has a good overview (that is pretty entertaining) here: http://www.youtube.com/watch?v=KEkR1ox_K10 We don't currently have an IndexedDb wrapper. IndexedDb (http:// www.w3.org/TR/IndexedDB/) is a successor to the defunct WebSQL and is a much more powerful datastore than Storage, supporting queries and such. GWT support for IndexedDb will require some serious work and I don't know of anyone looking into it at the moment. Philip On Oct 5, 1:43 pm, Jeff Chimene jchim...@gmail.com wrote: On 10/05/2011 10:26 AM, scott.ellswo...@gmail.com wrote: Howdy, all, Is anyone using webstorage or indexedDB client side data storage with GWT? Pointers to projects appreciated... Seehttp://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/googl... You can see an example athttp://code.google.com/p/gwt-sked/source/browse/trunk/%20gwt-sked%20-... Aside: I note that the WebStorage group reached an impasse and stopped supporting the spec last fall. Could you provide a pointer to this? I'd heard something about it, but I was under the impression that it was resolved by moving to a separate spec from the HTML 5 spec. I note further thathttp://www.w3.org/TR/IndexedDB/seems to be alive and kicking, but a brief reading seemed to indicate that this is a great system for key-object mappings, but not so great for the generic sql case of select rows from foo where name is blah group by this order by that kind of queries. ( might be wrong - section 3.1.3 keys can be DOMStrings. Since can supply a keyrange to an index, you may be able to generate the kind of selects I am used to, as long as you can generate an index such that the result of that query would be expressable as either indexkey==foo or low indexkey hig. Aside aside, does anyone have real world experience? I do not mind if the results only work on Chrome/FF/Safari, but IE would also be cool. The GWT storage API works for me in IE9. As usual, YMMV. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: scalable server backend for browser games
Angry Birds for Chrome has the same use-case you mention, and runs on AppEngine. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/WrffSMhnIjkJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: SimpleAppCacheLinker
The SimpleAppCacheLinker found in the mobile web app is very simple and caches all permutations of the JavaScript output in the app cache manifest file. The proper way to handle this is to do selection server-side and only deliver the relevant app cache manifest file with just a single JS artifact... until that functionality is available, I don't think the app cache linker is ready for inclusion in GWT. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/5enH-FM3Fa8J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Canvas and drawing Images that are not in the DOM
Good point, it's an unfortunate situation :/ The way I've handled this is to add the image to the page after adding the load handler: // add event handler yourImage.setVisible(false); RootPanel.get().add(yourImage); If you're waiting on hundreds of images to load, you may want to consider either ClientBundle (automatically groups images onto sprite sheets) or write a simple Loader class that attaches a load handler to each image, then gives you a callback when all of them have been loaded. Philip -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/TFKvdLTs-iMJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Canvas and drawing Images that are not in the DOM
Hey Jeff, We initially had a custom image bundle that produced large base64-encoded sprite sheets, and that did work--we just created an image with the base64 result and used it that way. Sadly, there are some memory issues with IE9 that prevent this from being feasible because IE ends up copying the base64 src string a few times in memory (a reasonable thing to do when uri's are small), which was a problem for us because we had such large images. When using many images on Canvas, our solution in ForPlay is to do the sprite sheeting manually (reduces 100 image requests to 1, along with some other GL advantages) and use the normal GWT Image load technique I posted above. Philip -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/TX3P7DrujkMJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Canvas and drawing Images that are not in the DOM
Hi Markus!
You certainly can do this. Just add an onload handler to your image and only
use your image after it has been loaded.
For example:
yourImage.addLoadHandler(new LoadHandler() {
public void onLoad(LoadEvent event) {
// free to use your image now!
}
});
Philip
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/qplLYfquoq8J.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Aw: Updated to GWT 2.3 - Still no Canvas support in IE9
Dennis, GWT's Canvas wrapper should be fully supported in IE9. There's a demo of it in action (with source) here: http://gwtcanvasdemo.appspot.com One thing to try--do you have !DOCTYPE HTML at the top of your html file? Without it, IE9 will switch to various previous rendering or document modes. Philip -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/iLj8JojfPi4J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: GwtCanvasDemo Question
Hi Sean, It's definitely not the cleanest code for understanding! The magic happens in lens.java::draw(backbuffer, frontbuffer). What's happening is the lens calls: front.drawImage(back.getCanvas(), 0, 0); which copies (blits) all the pixels from the back to the front. The backbuffer is never added to the root panel because it's only used as a temporary store of pixels for this operation. By the way, if you're interested in high performance javascript games, you may be interested in the ForPlay http://code.google.com/p/forplay/project. It's built using GWT and is targeted at multiplatform (including Html5) games. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/wfGgXY-ZzfgJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
[gwt-contrib] 100 column comments!
gwt-contrib, I just submitted r10381http://code.google.com/p/google-web-toolkit/source/detail?r=10381that changes the GWT comment style from 80 columns to 100 columns. If you receive the error Building workspace has encountered a problem - errors running builder 'Checkstyle Builder' on project gwt-user, you will need to re-import the GWT custom checks. To do this, copy svn/trunk/eclipse/settings/code-style/gwt-customchecks.jar into eclipse/plugins/com.atlassw.tools.eclipse.checkstyle_x.x.x/extension-libraries/gwt-customchecks.jar, then restart Eclipse. Thank you, Philip -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: image.getWidth() does not work in GWT. Any workarounds?
Did you try using the onload event in GWT, like you did in the JS?
For example:
public class MyTest implements EntryPoint {
public void onModuleLoad() {
final Image testImg = new Image(http://i.cdn.turner.com/
cnn/.element/img/3.0/global/header/hdr-main.gif?nocache= +
Math.random());
RootPanel.get().add(testImg);
printImageWidth(testImg); // will print 0
testImg.addLoadHandler(new LoadHandler() {
public void onLoad(LoadEvent event) {
printImageWidth(testImg); // will print a number
}
});
}
public void printImageWidth(Image image) {
System.out.println(image width is: + image.getWidth());
}
}
On Mar 23, 12:30 pm, Brandon Donnelson branflake2...@gmail.com
wrote:
Is there a way to get the width via the java code? I've documented it
and made an issue:
Issue:http://code.google.com/p/google-web-toolkit/issues/detail?id=3999can...
Getting images size width and height attributes does not work in GWT
Image.
GWT 2.2.0, Mac OSX, Chrome 10.0.648.151
This will not work:
Image testImg = new Image(/images/test.jpg);
FlowPanel panel = new FlowPanel();
RootPanel.get().add(panel);
panel.add(testImg);
System.out.println(testImg.getElement.getOffsetWidth= +
testImg.getElement().getOffsetWidth()); // nope
System.out.println(testImg.getWidth= + testImg.getWidth()); //
nope
System.out.println(panel.getOffsetWidth()= +
panel.getOffsetWidth()); // gets the windows/document/body width if
image overflows
System.out.println(panel.getOffsetHeight()= +
panel.getOffsetHeight()); // gets the windows/document/body width if
the image overflows
System.out.println(root width: +
RootPanel.get().getOffsetWidth()); // gets the windows/document/body
width width if the image overflows
This does work in native javascript:
script
function getWidthAndHeight() {
alert(' + this.name + ' is + this.width + by + this.height
+ pixels in size.);
return true;}
function loadFailure() {
alert(' + this.name + ' failed to load.);
return true;}
var myImage = new Image();
myImage.name = /images/test.jpg;
myImage.onload = getWidthAndHeight;
myImage.onerror = loadFailure;
myImage.src = /images/test.jpg;
/script
Brandon Donnelsonhttp://gwt-examples.googlecode.comhttp://c.gawkat.com
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: [gwt-contrib] Re: HTML5 Storage API in GWT. (issue1374803)
Allahbaksh,
This group (google-web-toolkit-contributors) is a little noisy and isn't
really used for general discussion. If you would like to discuss the
specifics of a review, you will probably get a better response if you use
the review site directly (http://gwt-code-reviews.appspot.com/1374803/). For
non-review questions, or anything else GWT, I would recommend the general
group: http://groups.google.com/group/google-web-toolkit/topics
http://groups.google.com/group/google-web-toolkit/topicsI will respond to
your questions though :)
1) IndexedDB is quite different from storage (storage is just key-value),
but they both share a similar purpose. The storage API being introduced in
this review is just for web storage and not for IndexedDB.
2) Sadly, browsers that do not support web storage are not supported with
the implementation being proposed in this review (see @PartialSupport).
Primarily, this is because cookies are a rough backend for storage (size
limitations, etc). The gwt-mobile-webkit project has an implementation for
older browsers that's backed by cookies, and a similar implementation may be
brought into GWT's storage implementation in the future.
3,4) WebSocket and WebWorker support are both on the table for GWTs
future--they just aren't here quite yet :)
Philip
On Fri, Mar 4, 2011 at 11:30 PM, Allahbaksh Asadullah
a.allahba...@gmail.com wrote:
HI,
Sorry this post is different from the review. I have following
questions
1)I am not sure whether this can be used with IndexDB which is new
HTML5 specification.
2)How about using some third party library for HTML5 storage on non
HTML5 supported browser like FF3.0 etc
3)Why not include WebSocket support right now. The code is of web
socket implementation is already their in wave trunk.
4)Inclusion on WebWorker
Warm Regards,
allahbaksh
On Mar 5, 4:28 am, jlaba...@google.com wrote:
This CL looks great. Cross off another one for HTML5 support.
http://gwt-code-reviews.appspot.com/1374803/diff/20/user/src/com/goog...
File
user/src/com/google/gwt/storage/client/StorageImplNonNativeEvents.java
(right):
http://gwt-code-reviews.appspot.com/1374803/diff/20/user/src/com/goog...
user/src/com/google/gwt/storage/client/StorageImplNonNativeEvents.java:69:
protected native void addStorageEventHandler0() /*-{
Make non-native
http://gwt-code-reviews.appspot.com/1374803/diff/20/user/src/com/goog...
user/src/com/google/gwt/storage/client/StorageImplNonNativeEvents.java:69:
protected native void addStorageEventHandler0() /*-{
make non-native
http://gwt-code-reviews.appspot.com/1374803/diff/20/user/src/com/goog...
user/src/com/google/gwt/storage/client/StorageImplNonNativeEvents.java:74:
protected native void removeStorageEventHandler0() /*-{
make non-native
http://gwt-code-reviews.appspot.com/1374803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: howto check HTML5 audio tag supported in a browser
You are probably trying to play an unsupported format :)
Firefox 3.6 doesn't support mp3. You can use audioEl.canPlayType() to
detect the available formats like so:
[... snip ...]
AudioElement audioEl = audio.getAudioElement();
audioEl.setAutoplay(true);
if (!audioEl.canPlayType(audio/mpeg;).equals(audioEl.CANNOT_PLAY))
{
audioEl.setSrc(smallmp3.mp3);
} else if (!audioEl.canPlayType(audio/ogg; codecs=\vorbis
\).equals(audioEl.CANNOT_PLAY)) {
audioEl.setSrc(smallogg.ogg);
} else {
RootPanel.get().add(new Label(no available media types));
}
audioEl.setControls(true);
audioEl.setLoop(false);
audioEl.setVolume(1.0);
RootPanel.get().add(audio);
} else {
RootPanel.get().add(new Label(audio not supported));
}
[... snip ...]
Philip
On Mar 3, 2:53 pm, Armishev, Sergey sarmis...@idirect.net wrote:
Thank you for the quick answer. When I moved forward with pure GWT based
approach I found that Audio object works on Chrome but not on Firefox
(3.6.13). Am I doing something wrong or it is some limitations? Below the
code. I made audio controls visible and actually see them on Chrome as well
as hear the sound but the same code doesn't show any audio player on Firefox.
I tested only in development mode. Here is the code
com.google.gwt.media.client.Audio audio =
com.google.gwt.media.client.Audio.createIfSupported();
if(audio != null) {
com.google.gwt.dom.client.AudioElement audioEl =
audio.getAudioElement();
audioEl.setAutoplay(true);
audioEl.setSrc(fullURL);
audioEl.setAutoplay(true);
audioEl.setControls(true);
audioEl.setLoop(false);
audioEl.setVolume(1.0);
RootPanel.get().add(audio);
} else {
//no HTML5 audio support
}
-Original Message-
From: google-web-toolkit@googlegroups.com
[mailto:google-web-toolkit@googlegroups.com] On Behalf Of Julien Dramaix
Sent: Thursday, March 03, 2011 8:13 AM
To: Google Web Toolkit
Subject: Re: howto check HTML5 audio tag supported in a browser
gwtmodernizr can help you to detect browser support for HTML5 and CSS3
features
Check at :http://code.google.com/p/gwtmodernizr/
On Mar 3, 12:31 am, John LaBanca jlaba...@google.com wrote:
GWT has an Audio widget for HTML5 audio support:
com.google.gwt.media.client.Audio.isSupported()
Thanks,
John LaBanca
jlaba...@google.com
On Wed, Mar 2, 2011 at 6:29 PM, Armishev, Sergey
sarmis...@idirect.netwrote:
I am new to HTML5 and have this simple question: what is the best way to
check that HTML5 audio tag is supported on the browser? In general I
would
like to be able to check for all/most of HTML5 tags. The only library I
found is Modernizr fromhttp://diveintohtml5.org/detectbutit doesn't
check for audio . Anybody knows and can recommend other libraries? Any
GWT
based libraries?
-Sergey
_
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.-Hide quoted text -
- Show quoted text -
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/google-web-toolkit?hl=en.
/PREBRspan
style='font-size:8.0pt;font-family:Arial,sans-serif;color:#003366'
_BR
This electronic message and any files transmitted with it containsBR
information from iDirect, which may be privileged, proprietaryBR
and/or confidential. It is intended solely for the use of the individualBR
or
Re: GWT 2.2 Canvas support for IE6 (GWTCanvasImplIE6)
Because of the difficulty of supporting IE6 fully via VML (including text, etc.) and still having reasonable performance, there aren't plans to support it at this time. The new Canvas implementation in GWT should have complete support across FF3.5, Chrome, Safari, and IE9, but there isn't a fallback provided for the older browsers. On Mar 1, 10:31 pm, Craig Mitchell craig...@gmail.com wrote: Hi, Are there any plans for Canvas to support IE6? It was supported via GWTCanvasImplIE6 in the gwt-incubator.jar which would implement the Canvas functionality via VML. Thanks. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
GWT 2.1.1 Release Candidate now available
GWT Community, We just launched the first release candidate for GWT 2.1.1! You can download this release from the GWT site here: http://code.google.com/p/google-web-toolkit/downloads/list, or as version 2.1.1-rc1 from Maven Central shortly. Please be aware that in this release candidate we have introduced three breaking changes from GWT 2.1: 1.) Request Factory has undergone a major overhaul based on community feedback. Some highlights include support for value objects, easier integration with existing server code via a service layer, and the promotion of the AutoBeanhttp://code.google.com/p/google-web-toolkit/wiki/AutoBeanframework to a top-level package. The full list of features and details on the breaking API changes are outlined here: http://code.google.com/p/google-web-toolkit/wiki/RequestFactory_2_1_1 2.) Cell Widgets have been improved with multiple bug fixes, API additions, and new features, including support for multiple selection via the mouse and keyboard. A breaking change has been introduced to the Cell API: a Context object is now passed to most Cell methods and the key value is no longer passed. The Context object contains the row and cell index, as well as the key value. This change will allow for additional context properties to be passed into Cell methods in the future without breaking API changes. 3.) The gecko user agent, which corresponds to Firefox 1.0, has been removed. The gecko1_8 user agent, which corresponds to Firefox 1.5 and newer, still remains. If you do not manually set the user agent in your gwt.xml file, you should not notice any change (except one less permutation during compilation). If you do set the user agent in your gwt.xml file, you may need to replace gecko with gecko1_8. If you are referencing gecko, you are almost definitely getting the wrong behavior for your application because it is using very old code bindings. One known issue is that samples/expenses is broken. You can build it byreplacing gwt.version 2.1.0 with 2.1.1-rc1 in the Expenses POM; however, you may still encounter Ishttp://code.google.com/p/google-web-toolkit/issues/detail?id=5741 s http://code.google.com/p/google-web-toolkit/issues/detail?id=5741uhttp://code.google.com/p/google-web-toolkit/issues/detail?id=5741e http://code.google.com/p/google-web-toolkit/issues/detail?id=574154http://code.google.com/p/google-web-toolkit/issues/detail?id=5741 7 http://code.google.com/p/google-web-toolkit/issues/detail?id=57411http://code.google.com/p/google-web-toolkit/issues/detail?id=5741o r others. Please give it a try and let us know what you think. Thanks, Philip Rogers on behalf of the Google Web Toolkit team -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Safe Html check?
As a best practice, it is usually best to unwrap (call
safehtml.asString()) as close to the value's use as possible. When
migrating you can replace many String occurrences with SafeHtml, and
widgets provide SafeHtml-aware methods that will automatically handle
your SafeHtml object. The toSafeString(String) method is private for
this reason--to encourage passing around SafeHtml instead of String.
Does an attribute-less span tag do anything? Allowing attributes
certainly makes span and div unsafe, as you point out with the
onclick example.
Creating your own sanitizer may be the way to go for your application,
as the one provided is quite simple (hence the name :) That said, it's
very easy to introduce security holes and I would recommend against
rolling your own. Large apps, for instance Google Wave, have been
written using SafeHtml and without custom sanitizers. (AFAIK)
Another option for you may be the SafeHtmlTemplates. The SafeHtml
guide I linked before gives all the details, and you can see some
additional uses of templates in practice in CellTable.java (and many
of the other Cell-based widgets.)
Example:
@Template(div style=\outline:none;\{0}/div)
SafeHtml div(SafeHtml contents);
Philip
On Dec 2, 2:15 pm, Ed post2edb...@gmail.com wrote:
Apearantly I was reading too fast :(...
I seem to need the class SimpleHtmlSanitizer .
Thanks for the tip.
I am using it now, but noticed that snaitizeHtml always returns an
SafeHtml object.
public static SafeHtml sanitizeHtml(String html);
That's often not what I want, especially not when migrating to it's
usage. I rather have it return a string, but that method is private:
private static String simpleSanitize(String text) {
As it safes me the creation of this object that I don't use.
I use it at this moment through a central method in my UtilsGwt:
public static String toSafeString(final String text) {
return SimpleHtmlSanitizer.sanitizeHtml(text).asString();
}
Besides that, I see you throw an exception if the specified html is
null:
public static SafeHtml sanitizeHtml(String html) {
if (html == null) {
throw new NullPointerException(html is null);
}
return new SafeHtmlString(simpleSanitize(html));
}
I would prefer you just return null, especially as it's valid to set
null as: element.innerHtml(null)
Hmmm I also see that span is escaped, so I probably better off
creating my own sanitizer ;)..
It would be nice if there would a default sanitizer that you can
configure maybe (flexible white list)..
Just one question: why are elements as div and span not whitelisted ?
I think because you could do something like:
div onclick=javascript:alert('send help. stuck in adom');
or not?
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Safe Html check?
Glad to hear you like SafeHtml!
In order to prevent various attacks, you have to check for much more
than just script tags. For example, the following can cause javascript
to be interpreted and would get by a script filter:
input type=image src=javascript:alert('send help. stuck in a
dom');
Therefore, you really need to be explicit about which strings are and
aren't dangerous. Anything provided by a user is potentially dangerous
and should be escaped (using SafeHtmlUtils.fromString(String)). If you
want a small amount of markup in user-provided strings (e.g., not
everything is escaped, tags such as b are allowed), you can take a
look at SimpleHtmlSanitizer.sanitizeHtml(String).
For more information, please check out:
http://code.google.com/webtoolkit/doc/latest/DevGuideSecuritySafeHtml.html
Philip
On Dec 2, 9:22 am, Ed post2edb...@gmail.com wrote:
I like the new SafeHtml functionality.
However, how can I best check if a string that I inject in a div
(example: HTML.setHTML(html)) contains script?
I now have made simple checks, like checking for the script (SCRIPT)
tag, but that's very fragil and little as you also have the click
events that can be set on an element, etc...
The SafeHtml code escapes all the html tags, which I don't want. i
only want it to escape the dangerous piece of texts. How to do this?
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: [gwt-contrib] Re: Added all safehtml packages. (issue771801)
Sure, I will add a note about the intended usage in the code.
I will be moving the existing widgets over to SafeHtml soon, and that will,
hopefully, provide some good examples as well.
Philip
On Thu, Aug 19, 2010 at 10:42 AM, Arthur Kalmenson arthur.k...@gmail.comwrote:
I'm just wondering, the idea of this is to display potentially unsafe
HTML we got from the server, right? Is there a way to discourage using
this to sanitizing HTML on the client before sending it to the server?
I can definitely see newer programmers assuming that doing this
sanitization on the client side is safe enough, when it's clearly not.
I guess some documentation to that effect would be enough.
--
Arthur Kalmenson
On Wed, Aug 18, 2010 at 10:11 AM, Christoph Kern x...@google.com wrote:
On Wed, Aug 18, 2010 at 01:44, t.bro...@gmail.com wrote:
On 2010/08/17 23:23:39, xtof wrote:
On 2010/08/17 23:05:06, tbroyer wrote:
Looking at the code more closely it would merely fail by overly
rejecting tags that are whitelisted: i.e. b foo=ishould be
bold would be sanitized to lt;b foo=ishould be bold and the
end part would be italicized instead of bold.
And that is exactly correct behavior for this class as document. It
only claims to accept HTML with attribute-free tags within the
whitelist. It doesn't claim to do anything particularly sensible
with input that doesn't fit this constraint; it does however claim
that whatever it outputs is safe (will not result in XSS/script
execution).
Oops, yes, sorry, I can't tell how it happened but I misread the
whitelisting code (matches the whole thing between '' and '', so any
attribute, or even whitespace, as in b bold/b, would make it fail
and thus be escaped).
It's fine then. Sorry again for the noise.
No prob, always better to err on the side of caution!
Still, there's a small issue with the fact that
SafeHtmlTemplatesGenerator doesn't use the HTML5 serialization algorithm
(or any similar one): @Template(br/) will result in br/br
which is interpreted by browsers as brbr [1], which makes it
impossible to generate a single line break in a SafeHtmlTemplates.
[1] http://www.w3.org/TR/html5/tokenization.html#parsing-main-inbody
(search for « An end tag whose tag name is br », it's there for
compat with the Web)
Agreed. Another potential problem with this parser is that it's too
strict
-- it insists on well-formed XHTML, but that's a much stronger constraint
than needed to ensure the SafeHtml type contract.
For example,
@Template(a href=\{0}\)
SafeHtml openATag(String href);
is perfectly safe, and might be useful in something where one needs to
conditionally assemble various pieces of HTML markup, like,
SafeHtmlBuilder shb;
//...
shb.append(openATag(someUrl));
if (...) {
shb.append(someThing)
} else {
shb.append(someThingElse);
}
To ensure the SafeHtml type contract, the parser need only record the
HTML-context (inner text, url-valued attribute, style, etc) of the
positional parameters, and require that the template ends in inner text
context (to ensure that SafeHtmls are safely appendable to each other).
Note that a bug in code like the above could result in non-well-formed
HTML
(like unbalanced tags), but not unsafe HTML that might cause XSS (that is
of
course absent bugs in the SafeHtml generators themselves).
As I'd mentioned, I'm proposing to replace the current XML based parser
with
the java streamhtmlparser, which has this property.
I'd be fine with removing the templating code from this change and land
it
separately along with the new parser.
cheers,
--xtof
http://gwt-code-reviews.appspot.com/771801/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
