Closed Bug 288325 Opened 19 years ago Closed 19 years ago

The 'interactive map' often does not appear until 'Reload' is clicked or one switches to the 'static map' and back again.

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: michael.graubart7, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050328
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050328

This website calculates routes and displays either a static or an interactive
map, the latter being the default option. Originally, I found that Mozilla would
not display the interactive map at all. I then downloaded and installed the
JavaEmbeddingPlugin.bundle in the Internet Plugins folder, and that allowed the
interactive map to be shown. But quite often (and I have been unable to work out
what the circumstances are) the interactive map does not appear until either I
click 'Reload', or I click 'Static map' at the top of the (empty) map winmdow,
and when the static map has appeared, click 'interactive map'. In Internet
Explorer, the interactive map appears straightaway every time.

Reproducible: Sometimes

Steps to Reproduce:
1. Install JavaEmbeddingPlugin.bundle.
2. In the given website, enter a departure address and a destination.
3. On the next page, confirm them and click 'Go'.
4. Wait for the website to calculate the route.
5. Observe the result.

Actual Results:  
Sometimes (not always) the map field remains blank. (See above for ways of
making the interactive map appear.)

Expected Results:  
The interactive map should have appeared as soon as the calculation had been
completed.

eMac G4, OS X 10.3.8, Classic theme.
I don't have any problems with this site.  You just have to wait for
the map to be initialized, which can take quite a long time.  While
you're waiting the applet just displays a bordered, blank window.  I
have exactly the same problem in Internet Explorer and Safari.  The
applet author(s) could do a better job of indicating that you're
waiting for the initialization to finish.

Tested on Mac OS X 10.3.8 with Firefox 1.0.2 and Java Embedding Plugin
0.9.0.

By the way, if this were a real Java Embedding Plugin bug, you'd want
to report it at the Java Embedding Plugin's web site (where you
downloaded it from):

http://javaplugin.sourceforge.net/
http://sourceforge.net/tracker/?atid=649116&group_id=107955&func=browse


I, on the other hand, DO have a problem with this site. On reading the e-mail
that contains Steven Michaud's comment, I tried the site again. After clicking
the final 'Go', I waited for about 2 minutes 30 seconds. Nothing had happened by
then. I then clicked 'Reload', and the map was complete and functional in 22
seconds.

This was the first time I had tried this site since first starting up my
computer this morning. I am under the impression that once one has tried the
site and got the map to appear in one of the two ways I have described, it will
then work normally for the rest of that computer session, even if one quits and
restarts Mozilla. Unfortunately, it also occasionally seems to work normally the
first time one tries the site in a new computer session — but not regularly.

With IE, the site functions correctly the first time. 

As for JavaEmbeddingPlugin, the effect of 'Reload' led me to believe that the
problem lies with Mozilla, not with the plugin.
I see that Steven Michaud used FireFox. I am using the Mozilla Suite. Can that
account for a difference in behaviour?

I tried to confirm my findings further, with frustrating results. I should say
that to avoid the effect of any extraneous variables, I used the same departure
and destination addresses in each case.

1. I tried the site again (without closing down and restarting the computer, but
having quitted Mozilla and restarted it). It did not work.

2. I tried it in IE and in Safari. Both worked.

3. I tried Mozilla again. This time it worked.

4. I closed down the computer, restarted it and tried Mozilla again. It still
worked.

5. I tried Mozilla with different departure and destination addresses, and it
still worked.

Can all this have to do with caches of temporary (and possibly invisible) files
that have a limited lifetime?

A further question: why does Mozilla require the downloading and installation of
JavaEmbeddingPlugin, when IE and Safari apparently do not? Should this (or a
corresponding plugin) not be bundled with Mozilla? 

I note that Steven Michaud used v. 0.9.0 of the plugin. I have been using v.
0.8.9; I shall download 0.9.0 and try all this again.
I just retried my tests with the Mozilla-suite nightly you appear to
have been using (2005-03-28-11-trunk), and got the same results.  The
applet first displays a blank, bordered "window" (or panel), and its
contents (a route map) only appear 20-30 seconds afterwards.  No
intervention was necessary to make the map appear.  I ran the test
twice, and rebooted between tests.  I used the same route each time,
but it was a different route than I had ever used before.

It's possible that what you're experiencing actually _is_ a problem
with the Java Embedding Plugin.  Upgrading to JEP 0.9.0 might help
... but I don't think that's terribly likely.  If I'm right, the main
issue is that the JEP has a lot of trouble with the map24.com applets
(which is what http://rp.rac.co.uk/routeplanner/ appears to use under
the hood).  I've done my best to accomodate these applets, and the
last two versions of the JEP certainly work better with them than
previous versions.  But sometimes you still get a blank display where
there should be a map.  I find that you can usually (always?) make the
map display by changing the size of the browser window (possibly only
slightly).

By the way, I'm the Java Embedding Plugin's author.

> A further question: why does Mozilla require the downloading and
> installation of JavaEmbeddingPlugin, when IE and Safari apparently
> do not? Should this (or a corresponding plugin) not be bundled with
> Mozilla?

The fact that a separate plugin is needed is Apple's fault.  The Java
Embedding Plugin may in the future be bundled with one or more of the
Mozilla-family browsers, but (I'd say) it first needs to get out of
beta and a suitable arrangement needs to be made with Mozilla.org.
For more information see the Java Embedding Plugin's Readme file and
skim through the messages at bug 197813.


Steven Michaud (Comment #4): As soon as I started downloading the Java Embedding
plug-in, I realized you were the author of the plug-in. I'm afraid that much of
what's in the Read Me is technically beyond me (I'm only a mere end-user and
occasional reporter of apparent or real bugs — a mere retired lecturer in a
music college, though in youth I was briefly a physicist and an electronic
engineer in the valve, pre-transistor era), but I've installed v. 0.9.0 and
changed its time stamp to today's. At the moment, and after one or two
re-bootings, the site is now behaving properly; but (to make sure that the
problem has nothing to do with the decay of temporary files) I shall try once
more tomorrow.
I give up on establishing any consistency. Yesterday morning I could not get the
thing to work on first trying it, but I thought I would confirm the malfunction
this morning. And this morning it worked straight away.
These latest tests were presumably done with JEP 0.9.0.

When, after waiting at least 30 seconds, the applet panel was still
blank, did resizing the window make the map appear?


I regret to say that I did not try resizing the window this morning, and now, of
course, the map appears by itself. I shall try the window tomorrow.
Well, I said I would try resizing the window the day after my previous trial,
but I can't, because this morning the map appeared by itself. If my hunch about
temporary files is right (i.e. that as long as these files remain in the system,
the map will appear), then it may be that it is not the change of date from one
day to the next that makes them disappear again, but a fixed number of hours
since the last opening of the map. If I make any further discoveries, I shall
report them. Otherwise, I shall have to leave the situation in its present
slightly undetermined state.
This time I waited about 36 hours before retrying the mapping site. I then went
to the site and entered a route.

The map did not appear even though I waited for over 60 seconds after the
calculation of the route had finished.

Then I tried resizing the window, and although I again waited for about 60
seconds, the map still did not appear.

Finally, I clicked 'Reload' and the map appeared in about 20 seconds.

Comment #4 mentions Map24 applets. Indeed, the text at the bottom of the map
window, before the map appears and when it has appeared, reads 'Applet
com.netsolut.map24.Map24 started'. So after the above trial, I searched for
'map24' and found the following:

Map24ExceptionHandler.class-1c0896d4-4cc15ea4.class     30 March, 19:45
Map24ExceptionHandler.class-1c0896d4-4cc15ea4.idx       2 April, 18:36
symMap24_0.gif-1ed2d600-191437a3.gif                    11 January, 14:55
symMap24_0.gif-1ed2d600-191437a3.idx                    4 April, 23:31

The fourth date and time corresponds to my trial tonight, reported on above. The
second one corresponds (as far as can I recall) to the last time I tried the
mapping procedure. I can no longer identify the remaining two dates and times.
> Then I tried resizing the window, and although I again waited for
> about 60 seconds, the map still did not appear.

It sounds like your problem, whatever it is, isn't the one I described
in comment #4.

> Finally, I clicked 'Reload' and the map appeared in about 20 seconds.

20-30 seconds has always been how long it takes for a route map to
appear in my tests.  Presumably this includes the time needed to
download all the route-specific data, from scratch.  Further
confirmation that your problem is not what I described in comment #4,
and probably isn't JEP-specific.

You may be right to suspect a problem with (cached) temporary files,
or possibly with your browser or JVM settings.  If the problem is
specific to the caches or settings in your own account (the one you
usually use to log on to OS X), here's something that might clear it
up:  Create a new account (don't just re-use an existing one), log on
to it, and use Mozilla-plus-JEP from there to look up a route.  If
this _does_ avoid the problem, try clearing your Java and browser file
caches while logged into your regular account (use the Java Console to
clear the Java file cache), to see if that helps.

> Map24ExceptionHandler.class-1c0896d4-4cc15ea4.class     30 March, 19:45
> Map24ExceptionHandler.class-1c0896d4-4cc15ea4.idx       2 April, 18:36
> symMap24_0.gif-1ed2d600-191437a3.gif                    11 January, 14:55
> symMap24_0.gif-1ed2d600-191437a3.idx                    4 April, 23:31

I found files with similar names on my system.  They were all in one
of the Java file-caches under my home directory.  Their presence is
(of course) completely normal.  Though I have to say I didn't see
Map24ExceptionHandler.class.  The next time you have a problem, take a
look at your ~/Library/Logs/Java Console.log file.


Interesting: this misbehaviour no longer happens in Build 20050409, but I have
just checked, and it does happen in Build 20050331. So it does seem to be
Mozilla-connected.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

This bug has got worse! Previously, one could make the 'dynamic map' appear by
clicking 'Reload'. Now it does not appear at all. In Safari it does, so this is
not a temporary malfunction of the website.
Which versions of which Mozilla.org browser(s) are you using?  What version of
OS X are you running on?  What version of the Java Embedding Plugin are you
using?

I just tried Firefox 1.0.7 on Mac OS X 10.2.8 and had no problems at all.
Even the loading speed seemed quite a bit faster than it was previously.

I asked the planner to plot a route between "London" and "Stonehenge" :-)


Steven, re #15: I am using an eMac G4 with OS X 10.3.9. In build 20050915 it
does not work. In build 20050927 it does (as you say), but unfortunately this
build has several other, more serious bugs, so I am not currently using it.
> build 20050915

You don't say "build 20050915" of _what_ ... but in this case it doesn't
matter.

Apple recently released a Java Security Update for Mac OS X 10.3 that broke
the Java Embedding Plugin.  A couple of days later I released a new version
that fixed the problem.

https://bugzilla.mozilla.org/show_bug.cgi?id=308549

For about the last month, Mozilla.org browser nightlies, alphas and betas have
bundled copies of the Java Embedding Plugin (in their Contents/MacOS/plugins/
directory).  But it's only as of 2005-09-27 that they're starting to bundle a
JEP version (0.9.4+a) that's compatible with Apple's Java Security Update for
OS X 10.3.

You've got problems with the 20050927 nightly -- so just downloading the
latest nightly isn't (yet) an option.  To keep using your 20050915 build,
first download the latest JEP version (0.9.4+a) and install it to your
/Library/Internet Plug-Ins/ directory (as per the instructions in the JEP
Readme file).  Then delete JavaEmbeddingPlugin.bundle and MRJPlugin.plugin
from your 20050915 build's Contents/MacOS/plugins/ directory.


Re: Comment #17. Steven, Thank you for this detailed information.

1. I am using Build 20050915 of SeaMonkey. I did not say so because I stated
that I was referring to SeaMonkey (or rather, at that time, the Mozilla
Application Suite) when I made my original bug report.

2. I have now downloaded 0.9.4+a, installed it and checked the time-stamps (as
per 'Read Me').

3. There is no Contents/MacOS/plugins directory belonging to my SeaMonkey or
Mozilla application. Searching for the two plugins you have told me to delete
only finds the ones I have just installed in the Library/internet plug-ins
directory -- so, of course, I did not delete them again.

4. I then restarted my computer.

5. The interactive map still does not appear, even after I have clicked 'Reload'.
> There is no Contents/MacOS/plugins directory belonging to my SeaMonkey or
> Mozilla application.

Here's how to find it (I assumed you already knew):

Control-click (or right-click if you have a two-button mouse) on SeaMonkey (or
any other Mozilla-family browser), then choose "Show Package Contents".  A
window will open up in which you can browse to the package's
Contents/MacOS/plugins directory.


Miracles will never cease! Steven, thank you for the instructions — now it all
works.
ok, then it's a works for me in Firefox 1.5 beta 1, with JEP 0.9.4+a, and bug
308549. The combination is no available in a nightly, or will be in Firefox 1.5
beta 2.

(JEP 0.9.4+a solved a ton of problems)
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.