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
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.