412187 - Metars java tool no longer works

Status: VERIFIED DUPLICATE of bug 416716

(Camino Graveyard :: Plug-ins, defect)

Description

[Richard Leonetti]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.11) Gecko/20071128 Camino/1.5.4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.11) Gecko/20071128 Camino/1.5.4

Data does not load, but can be loaded by 3 "reloads". Then the mouse selection tool used to zoom the map does not work to zoom the display. It selects the area but the zoom does not happen.

Reproducible: Always

Steps to Reproduce:
1.click "Metars Java Tool"
2.When data does not load, "reload" screen several times until it does.
3.Rt. click mouse and select an area of the map. Screen should zoom but nothing happens.
Actual Results:  
Map just sits

Expected Results:  
Screen should zoom to selected area. This worked fine in earlier versions, and still works fine using safari.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This WFM in a recent branch nightly and in 1.5.4 with a fresh profile on 10.5.1.

Comment 2

[Chris Lawson (gone)]

This worked about a week or two ago when I tried it on trunk, too.

Have you done anything with your Java plugin (tried a pre-release version of the JEP, etc.) that might have caused Camino to get confused? Are you sure the JEP in Camino itself is the only JEP on your system?

Comment 3

[Richard Leonetti]

I am not sure and do not know how to find out. I do know that Safari works just fine on the same site.

Comment 4

[Chris Lawson (gone)]

If you're not sure, you probably haven't ;)

This works OK for me on 10.5.1 with a fresh profile too; make sure you scroll the screen to get the applet to redraw and make sure you actually let all the data load (it took ~60 sec on a DSL connection for all of it to load) before you try it.

To try a fresh profile, use Troubleshoot Camino:

http://pimpmycamino.com/parts/troubleshoot-camino

See if a fresh profile fixes it. If it does, the problem is (most likely) somewhere in your prefs.

Comment 5

[Richard Leonetti]

Secret is you must scroll screen. Works fine, thank you

Comment 6

[Chris Lawson (gone)]

Now, the question is, why doesn't the plugin redraw properly on its own? Smokey, do you know if there's another bug on this somewhere already (making this a dupe), or should we use this bug for that purpose? Steven, any ideas?

Reopening until we decide what to do with this.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I didn't have to scroll, but I've certainly seen that in other cases.  I think there's a bug on it, but I'm not sure.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

I didn't have to scroll either.  But like others, I've seen this kind
of thing before.  I don't think there's one specific bug that
addresses the problem directly, but I'm well aware of it.

Here's a simple, precise description:  Java applets sometimes don't
display properly (or at all) when they're first loaded.  This is true
of all Mozilla.org browsers (which use the JEP).  The workaround is to
scroll or resize the browser window.

Over the years I think I've decreased the problem's severity ... or
maybe I've just benefited from the appearance of newer, faster
computers :-)  But in any case this problem won't be (and can't be)
resolved completely until Mozilla.org browsers change how they load
plugins.

The "occasional no display on load" problem is one of a class of
problems that happen when a Java applet is loaded.  All are
(ultimately) due to the fact that while Mozilla.org browsers load
plugins synchronously (they expect the plugins to be fully functional
as soon as the command to load a plugin returns), Apple's JVM is
initialized (and applets are loaded into it) asynchronously, on
secondary threads (neither Apple's JVM nor any Java applet are ready
for use as soon as the command to load a plugin returns).

I've hacked around this problem by spinning the main event loop until
I think the JVM and the applet being loaded are ready (_then_
returning from the call to load a plugin).  But using this method
creates problems of its own -- for example the "occasional no display
on load" problem, and the large delays you see when you try to load
pages containing many Java applets.

What the Mozilla.org browsers need to do is to have both a command to
load a plugin and a callback that the plugin host (e.g. the JEP) can
call to indicate that the applet has finished loading.  The browser
shouldn't start displaying the applet until the callback has been
called (and a successful load has been indicated).

I realize this is a tall order.  But, now that I'm working for Mozilla
Corp, I may have some influence in this area, and I may be able to
contribute to a solution.  My hope is to get this into Mozilla 2.0
(the "2.0 branch", as opposed to the "1.9 branch" that Firefox 3 will
be released on).

Comment 9

[Chris Lawson (gone)]

Rather than morphing this bug, let's get a new bug filed for comment 8 (in the appropriate component) and dupe this one to that bug.

cl

Comment 10

[Stuart Morgan]

Steven, have you filed the bug for comment 8?

Comment 11

[Steven Michaud [:smichaud] (Retired)]

Yes, I've finally done it -- bug 416716.

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Duping this there, then.  (If you want it to stay open for whatever reason, it should probably live in Core:JEP rather than in Camino.)