Can someone confirm this ImageBundle bug for me?
rusty
I filed the following bug to do with ImageBundle loading under HTTPS:
http://code.google.com/p/google-web-toolkit/issues/detail?q=&can=2&id=1172
Does someone else out there have a HTTPS environment that they can try
the ImageBundle on? It could just be me being stupid (wouldn't be the
first time, and I'm sure not the last), and if so I'd like to know so
that I can look into it more.
thanks,
Rusty
Jason Essington
the images appear just fine.
-jason
Sumit Chandel
Thanks for entering what could be a potential bug. Is the URL to your app publicly available? If so, it would be great if you could update the issue with it to help us track down the cause of the problem.
Also, have you tried running your host pages in a regular HTTP environment? Trying that out might help determine whether the usage of HTTPS is the culprit or if there is a problem in the ImageBundle implementation.
Thanks,
-Sumit Chandel
rusty
I have tried the page over HTTP, and it loads just fine. I've updated
the issue with some more information, but basically I get a mixed
security warning, and then only the clear-cache.gif file is present
where all the images should be. If I respond no, then none of the
images are loaded. Just a question on that - why is it that I get the
mixed security warning? Isn't all the ImageBundle magic happening over
HTTPS as well?
The server it's running on is not publicly accessible yet, so I will
either look at temporarily opening it up, or perhaps making a small
test case.
thanks for the response so far.
Rusty
Jason Essington
There were some other issues with iFrames (I think) that yielded the
same issue in IE.
In that case a blank URL was perceived by IE as an insecure page.
The activity monitor in Safari shows that everything is loaded via
HTTPS, and in fact, my test server uses odd port numbers, so even if
it was trying to load something via http, it would meet with no
success, so I've gotta believe the warning is an artifact.
That said, there is still a bug that needs to be dealt with since
image bundle certainly shouldn't be triggering that warning.
As I said, all of my image bundles are working fine over HTTPS even
on IE (the mixed security warning withstanding).
perhaps you could post a small snippet of code demonstrating how you
are using the Image bundle since that may be partially what is
triggering your issue.
I'm using the myImageBundle.mySnippet().applyTo(myImage); version,
what does your code look like?
-jason
rusty
I've sent you an email with the details about how to log into our
application. In terms of code Snippets, mine looks like:
public interface Images extends ImageBundle {
/**
* @gwt.resource preview.gif
*/
AbstractImagePrototype preview_folio();
//etc
}
followed by:
private Images images = (Images) GWT.create(Images.class);
then calls like:
images.preview_folio().createImage();
I'm not familiar with the applyTo() version? I was just copying how
the RichTextToolbar was done (which by the way doesn't work in our
environment either, exactly the same symptoms)
Rusty
> > mixed security warning? Isn't all theImageBundlemagic happening over
ISHTIAQ
have you insured this?
ref: http://code.google.com/p/google-web-toolkit/wiki/ImageBundleDesign
--------------------------------
Configuring Your Module for Image Bundles
To use image bundling, your module needs to explicitly inherit
ImageBundle.
Behavior/Restrictions/Caveats
For the ImageBundle-compatible type T specified in
GWT.create(T.class), the following must be true:
* T must be an interface, not a class.
* All of the methods on T must conform to the required signature
(see above) and must specify @gwt.resource in a metadata comment.
The generated image bundle output file will
* have same type "png"; files referenced via @gwt.resource will be
converted
* be named md5.cache.ext, where md5 is a hash of the bytes in all
the consistuent images and ext is the image file type
* be written into the output directory for the module (that is,
the same location into which compiled JS is written
--------------------------------
rusty
Your module needs to explicitly inherit ImageBundle
What do you mean by this? I'm using the Mail sample as my template,
and I don't see any import statement in the Mail.gwt.xml. If you just
mean an import statement in the actual code, then yes.
Like I said, the ImageBundle I'm using works fine in all browsers over
HTTP, and in all but IE over HTTPS.
Rusty
p.s. Jason and Sumit: I've just realised that the link I sent you
wouldn't have worked up until now, so if you tried before and had no
joy, please try again.
Jason Essington
just for kicks, try this
Image myImage = new Image();
// add image to your panel
images.preview_folio().applyTo(myImage);
That's the way I have been using ImageBundle, and it seems to be
working for me, so maybe there's some problem with constructing a new
image directly from the image bundle when running over HTTPS in IE.
at least if this works, then we've narrowed the problem down a bit.
-jason
rusty
I tried:
Image image = new Image();
//added the image to my panel
images.edit_folio().applyTo(image);
but I still get the same result. I even tried putting the call to
applyTo in a DeferredCommand but still no dice. I tried taking off all
the custom CSS styling I had on the image, but still no go. Now I'm at
a loss. The thing I find weird is that even the RichTextToolbar that I
copied straight from the samples doesn't work. I guess maybe my next
step is to try running the kitchen sink example over HTTPs, and see
what happens with the toolbar on that. Is that something you can do
easily in Google HQ?
Rusty
On Jun 8, 11:39 pm, Jason Essington <jason.essing...@gmail.com> wrote:
> Rusty
>
> just for kicks, try this
>
> Image myImage = new Image();
> // add image to your panel
> images.preview_folio().applyTo(myImage);
>
> That's the way I have been usingImageBundle, and it seems to be
stuckagain
When I try to use a Tree in GWT using SSL, we get the same mixed
content warning.
I looked through the code and I see that it uses an ImageBundle as
well... so I'm guessing that I have the same issue that is discussed
here.
FramePanel and NamedPanel have the dialog of mixed content. These use
an IFrame and if the URL is not set, IE will use about:blank. These
classes will need to be modified so that they put this attribute in
IE.
David
> > >>>> -Sumit Chandel- Hide quoted text -
>
> - Show quoted text -
stuckagain
ClippedImageImplIE6, that a img tag is created with src="about:blank".
By replacing it with "javascript:''" the mixed content warning is
gone.
Can you maybe try this (just unjar gwt-user.jar, locate the file and
change the code as described above, jar again).
> > - Show quoted text -- Hide quoted text -
Jason Essington
You can just fire up kitchen sink straight from the filesystem, it is
in the samples folder.
I wonder what the difference between your app and mine is ...
my ImageBundles are working via https, but yours certainly aren't. I
wonder what else could be different.
-jason
rusty
The only difference I can maybe think of is that mine is not running
locally (but then yours may not be either) and that mine is using a
self-signed certificate so that you get those certificate warnings
(but then yours may be as well?).
I will try the fix for the mixed content warning suggested by
stuckagain above, and see if that fixes this problem as well.
Rusty
On Jun 13, 12:54 am, Jason Essington <jason.essing...@gmail.com>
rusty
problem go away. I also tried moving the image to an unprotected area
of our website (where it doesn't require a username or password), but
that made no difference.
Finally I set up a HTTPs environment on my own machine and gave it a
whirl, still no go. So I loaded in the kitchen sink example and it
works great. So all I have to do now is figure out the difference
between the kitchen sink example and my own code.
Rusty
rusty
happening. I tried putting the kitchensink example into my secure
realm (I'm running this under Glassfish) and the images dissapeared
just like in my application. I then removed all of the security
settings from my web.xml and it worked.
I guess the obvious question is why the ImageBundle fails, only in IE,
and only in a security realm, even if you've already been
authenticated. Is it doing something super fancy?
Rusty
Jason Essington
The only difference I can maybe think of is that mine is not running
locally (but then yours may not be either)
and that mine is using a
self-signed certificate so that you get those certificate warnings
(but then yours may be as well?).
Jason Essington
filenames into the URL bar shows the whole imageBundle image, so they
will clearly load and display via https, I wonder what weirdness is
happening with Glassfish/IE/HTTPS/ImageBundle
Just another wild guess, but do regular (unclipped) .png images work
when used with the Image widget (via https on IE from glassfish)?
-jason
tsch...@gmail.com
1.4, we started using ImageBundle and now get the warning in IE over
HTTPS, "This page contains both secure and nonsecure items. Do you
want to display the nonsecure items?".
Tom
On Jun 6, 10:15 pm, rusty <rustysh...@gmail.com> wrote:
> Hi,
>
> I filed the following bug to do with ImageBundle loading under HTTPS:http://code.google.com/p/google-web-toolkit/issues/detail?q=&can=2&id...
rusty
covered by issue 1200. As far as I can see it's already been fixed in
SVN.
Jason: Normal unclipped images load without any problems.
I have sent Rajeev enough details to replicate this problem, but my
kung fu is not good enough for me to find problem inside GWT.
Rusty
On Jun 14, 2:09 am, "tschro...@gmail.com" <tschro...@gmail.com> wrote:
> My project is experiencing the same issue as well. After moving to GWT
> 1.4, we started usingImageBundleand now get the warning in IE over
> HTTPS, "This page contains both secure and nonsecure items. Do you
> want to display the nonsecure items?".
>
> Tom
>
> On Jun 6, 10:15 pm, rusty <rustysh...@gmail.com> wrote:
>
> > Hi,
>
> > I filed the following bug to do withImageBundleloading under HTTPS:http://code.google.com/p/google-web-toolkit/issues/detail?q=&can=2&id...
>
> > Does someone else out there have a HTTPS environment that they can try
> > theImageBundleon? It could just be me being stupid (wouldn't be the
rusty
Because we have Apache sitting in front of our Glassfish anyway, we
just told apache to serve anything that is *.gif and *.png in the
directory where our GWT project is deployed, and voila, the problem is
no more.
I can't believe I didn't think of that earlier, but oh well, at least
we have IE working now :)
Rusty
sumitc...@google.com
to work around in IE and Tomcat/GlassFish.
The problem begins with the fact that IE expects that any content it
loads that will be used by a plugin will be cached. The ImageBundle
makes use of the AlphaImageLoader plugin, and so IE expects that any
content that the plugin will use will be cached. We're in the clear
so far, but here follows the last step that completes the puzzle to
this problem. Tomcat and Glassfish both set the Pragma: No-cache and
Cache-Control: no-cache HTTP Response headers whenever:
1) files are served up over SSL, or
2) the web application has a security constraint set on these files
(URLs)
IE obeys these headers and doesn't cache any content served up under
these conditions. Since the .png file isn't cached, the generated
image bundle is not available to the AlphaImageLoader and so we end up
with blank space where the images should be.
This is a problem with Tomcat/Glassfish's default behavior, and the
fix is to change their configurations so that they don't tell browsers
not to cache images. One way to do this is to set up a filtering
servlet that could explicitly set the cache headers so that the
browser caches the content.
Rajeev discovered the cause of the problem and describes it in greater
detail on Issue #1172. He also lists other workarounds to this
problem that you may want to check out depending on your preference/
situation.
We'll be making an update to the Developer Guide and ImageBundle
javadoc so that developers using ImageBundle are aware of the issue
early on.
Glad we've gotten to the bottom of this problem. Keep on codin'!
-Sumit Chandel
On Jun 13, 6:15 pm, rusty <rustysh...@gmail.com> wrote:
> I figured out an easy workaround (well for us anyway)
>
> Because we have Apache sitting in front of our Glassfish anyway, we
> just told apache to serve anything that is *.gif and *.png in the
> directory where our GWT project is deployed, and voila, the problem is
> no more.
>
> Ican't believe I didn't think of that earlier, but oh well, at least
> we have IE working now :)
>
> Rusty
>
> On Jun 14, 9:03 am, rusty <rustysh...@gmail.com> wrote:
>
> > Tom: The issue you are talking about is slightly different and is
> > covered by issue 1200. As far as Icansee it's already been fixed in
> > SVN.
>
> > Jason: Normal unclipped images load without any problems.
>
> > I have sent Rajeev enough details to replicate this problem, but my
> > kung fu is not good enough formeto find problem inside GWT.
>
> > Rusty
>
> > On Jun 14, 2:09 am, "tschro...@gmail.com" <tschro...@gmail.com> wrote:
>
> > > My project is experiencing the same issue as well. After moving to GWT
> > > 1.4, we started usingImageBundleand now get the warning in IE over
> > > HTTPS, "This page contains both secure and nonsecure items. Do you
> > > want to display the nonsecure items?".
>
> > > Tom
>
> > > On Jun 6, 10:15 pm, rusty <rustysh...@gmail.com> wrote:
>
> > > > Hi,
>
> > > > I filed the followingbugto do withImageBundleloading under HTTPS:http://code.google.com/p/google-web-toolkit/issues/detail?q=&can=2&id...
>
> > > > Doessomeoneelse out there have a HTTPS environment that theycantry
> > > > theImageBundleon? It could just bemebeing stupid (wouldn't be the
> > > > first time, and I'm sure not the last), and if so I'd like to know so
> > > > that Icanlook into it more.
>
> > > > thanks,
>
> > > > Rusty