51068 - # fragments in URL's don't always reach the plugin

Status: VERIFIED WORKSFORME

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Kevin McCluskey (gone)]

A test plugin which illustrates whether the browser correctly handles passing 
the "#" fragments to plug-ins works on N4.x but does not work with N6. 

The # fragment case is an important high use scenario for Web graphics, so we 
don't want to miss the opportunity to verify or fix 6.0.

Comment 1

[Kevin McCluskey (gone)]

Nominating for nsbeta3.

Comment 2

[ekrock's old account (dead)]

Kevin, could you please supply more details about:
- what "# fragments" are
- what purpose they serve
- how they are passed, and from what to what (content to plug-in? JS to 
plug-in?)
- what plugins depend on them (Flash? Real?)

Comment 3

[Kevin McCluskey (gone)]

My understanding is the # fragments are used to allow the plugin to jump to a 
particular location with the file referenced by the URL. 

All we need to support is passing the # through to the plugin. The plugin will 
take care of jumping to the fragment.

At this point all this bug is about is trying to verify that the # is passed 
through to the plugin. The verification is being done using a test plugin. The 
problem is the test plugin does not work with N6 for some reason. It works fine 
on N4.x.

Comment 4

[ekrock's old account (dead)]

Nominating as dogfood as this bug appears to be blocking eng/QA from running a 
test plug-in used to verify correction functioning of the Mozilla Plug-in API.

Comment 5

[leger]

Putting on [dogfood+] radar.

Comment 6

[Kevin McCluskey (gone)]

Clearing the dogfood+, for reconsideration. The test plugin is not blocking
Netscape eng/QA. It is blocking an outside contributor from verifying that we
handle the # fragment correctly.

Comment 7

[leger]

Putting on [dogfood+] radar.  blocking QA

Comment 8

[av (gone)]

Kevin, I still don't understand what is passed where. What should I do to see 
the problem myself? Do you have the actual plugin?

Comment 9

[Kevin McCluskey (gone)]

I've asked [e-mail] to provide info on getting the plugin.

Comment 10

[Kevin McCluskey (gone)]

from  [e-mail] 

Attached you will find a zip file containing a simple HTML page and two 
connected CGM files.  Please unzip the file and put the contents into an 
arbitrary directory.
 
Now download our MetaWeb distribution from www.ematek.com/01frame.htm.  Execute 
the mwsetup.exe and install all three components (stand-alone, ActiveX, 
Plug-In).  You have to make a choice during the installation and due to a 
recent problem in the setup only all three components work together.  We will 
fix that ASAP.  In any case, choose NetScape as the default viewer for CGM files 
when prompted for.
 
Once the installation is done launch the test.html test page and click on the 
links to the two CGM files.  The Plug-In will load them (at least, in NN 4.7x) 
and highlight a certain graphical object while processing the #-fragment.  If 
you try to do the same in NN 6.0 beta the Plug-In will not even be launched. 
That is our major problem right now.
 
We are working on a simplified Plug-In, which only shows the received linkURI's 
plus the fragments and then terminates.  We will prepare a more sophisticated 
test case for this Plug-In and then pass it on to the CGMOpen group in source 
code form.  But for the moment, to get this thing started,  please use our full 
product.  Please feel free to place the according deliverables where ever you 
want.

Comment 11

[Kevin McCluskey (gone)]

Attachment: test html file

Comment 12

[Kevin McCluskey (gone)]

Attachment: zipped test files

Comment 13

[Kevin McCluskey (gone)]

Changing summary from:
Important test plugin does not work with N6
to:
CGM plugin does not work with N6.

Clearing [dogfood+] BLOCKS QA for reconsideration. QA is NOT blocked by this 
bug.

Comment 14

[Jim Roskind]

If QA is not blocked, I don't see this as preventing usage, so marking
dogfood-minus.

..that said... plugins are quite crucial to utility of N6, and loosing a major
aspect of plug-in support (see prior comments) is Very Bad (TM).  Hopefully this
can get a beta3-plus and be dealt with in short order.  It would probably be a
P1 or P2 level issue.

If the comments above about support "#"stuff are in error, and this feature is
NOT common to many plugins, then that info should be added to the bug.

Thanks,

Jim

Comment 15

[ekrock's old account (dead)]

The CGM data format isn't widely used on the web (no offense, CGM fans) so this 
isn't a critical issue for ordinary consumers. The greater concerns here are (1) 
are we failing to be b.c. with # (2) how many other plug-ins use # (3) is this 
exposing more fundamental lack-of-backward-compatibility issues in the Mozilla 
Plug-in API?

So if the problem is specific to this plug-in in particular, we could live with 
it for RTM and fix later; but if this # issue will affect other plug-ins (can 
anyone give examples) it's of greater concern.

Comment 16

[karnaze (gone)]

Marking nsbeta3-.

Comment 17

[chris]

CGM isn't widely used, true. Just some little users like the entire Aeronautics, 
Automotive, and Defense industries. And of course the # bug (which is in both NS 
and IE) has limited adoption of WebCGM.

The fragment is used for the same sort of things that the fragment in HTML is 
used for - navigating to somewhere other than the root of the resourse. In HTML, 
that means moving to some other part of the document. In WebCGM, it means 
selecting which picture to display (CGM files can contain multiple pictures), 
what part of it (CGMs can be zoomed and panned) and what parts to hilight. SVG 
has similar needs, navigating to particular views or portions of the graphic.

The problem itself is *not* specific to CGM. It also affects any other format 
that has need of internal addressing - and will apply more and more as we see 
more XML usage.

And all that needs to happen is that the browser re-attaches the fragment and 
sends it on t the plugin, rather than stripping it off.

Comment 18

[chris]

Why is this bug listed as PC only and NT only? OS and platform should both be 
*all*, no?

Comment 19

[Kevin McCluskey (gone)]

Changing platform/OS to ALL

Comment 20

[ekrock's old account (dead)]

Hi chris, many thanks for all the info! There are many more bugs that we would 
like to fix than we will be able to fix for RTM. So that you understand our 
triage process: Netscape 6 RTM is targeted at intermediate consumers rather than 
enterprise customers, so the specific industries you mentioned would make this 
bug a priority to fix for a future enterprise-targeted release rather than for 
RTM.

The question then becomes: "What plug-ins other than WebCGM require this 
functionality?" In particular, "Do any plug-ins widely used by consumers require 
this functionality?" Marking FUTURE until we get proof that this must really be 
fixed for RTM.

Comment 21

[lofton]

Hi, I'd like to add a comment to the 10/2 exchange between Chris and 'ekrock'.  
Specifically, to amplify Chris's comment on the bug's effect on XML content:  
the bug will prevent object addressing and linking between SVG content and any 
other Web content type (e.g., HTML).  SVG is nearing completion, and it looks 
likely to be a huge end-user standard (not limited to enterprise clients).  Its 
target clientele -- most places that GIF and JPEG are used now.  Also this 
should be clarified:  it is uncertain whether the beta 6.0 release suffers from 
the bug, because the investigators (same team that verified and fixed it in IE 
-- see message from 'ull') have not been able to get (several) successful 4.73 
plugins to even load with beta 6.0.  That is the first hurdle.  Then it can be 
ascertained whether there is or is not a "#" fragment bug in 6.0.  

Comment 22

[John Rauland]

At General Motors we are introducing CGM graphics for our service literature, 
which will be delivered via the Web to our retailers and service technicians.  
Most of our service information is very heavily graphics based and we use a 
large number of links in the graphics to navigate to secondary information. The 
support for the CGM fragment identifier "#" is crucial to the successful launch 
of our wiring diagram application and we cannot do without this linking 
functionality.

Comment 23

[ekrock's old account (dead)]

Hi Lofton -- Many thanks for the info! So this issue (if it's real) is a blocker 
for SVG support in the browser. Netscape 6.0 RTM won't support SVG, so that's 
not a blocker for Netscape 6.0 RTM, but we will need to be sure to get this 
fixed in time for any future release of Netscape 6.x that includes SVG support.

John -- Are you planning on using the first release of Netscape 6.0 at GM as 
your enterprise client? Please feel free to contact Kevin Murray at Netscape 
([e-mail]) for information on enterprise-specific functionality.

Comment 24

[chris]

ekrock said "Netscape 6.0 RTM won't support SVG, so that's not a blocker" which 
is incorrect;  NS 6.0 won't have native support (true) but that means that it 
has to rely on a plugin (such as the Adobe plugin that works now with NS 4.x) 
and that plugin has now and will continue to have problems due to the # 
fragments being stripped, until the bug is fixed. Once there *is* native 
support, then it becomes irrelevant (for SVG) whether plugins have a problem 
....

Comment 25

[Harry Whittaker]

To Ekrock and Netscape and all other interested in object addressing.  The Navy 
an other DOD activities are moving toward placing documentation on the web.  
This documentation is created internally and by major DOD suppliers such as 
Boeing and Raytheon.  Both DOD and our large commercial partners use much 
smaller organization to create and modify this documentation.  For 2-D vector 
graphics many are/or will be mandated to follow new Navy policy requiring use of
open standards such as webCGM.  We are following the graphic standards from the 
W3C and watching the development of SVG.  We have previously worked with the 
other major browser manufacturer to help allow implementation of the # symbol 
to allow for object addressing.  We also need this to work in your browser.

Comment 26

[Kevin McCluskey (gone)]

spam -- test

Comment 27

[lofton]

The problem description needs clarification.  Indeed, a 4.73 plugin could not be
successfully adapted and made to function on 6.0, and this still remains a
problem.  It might be inferred from the description and bug thread so far, that
4.73 correctly handles "#" fragments.  This is incorrect.  We have verified
this mishandling:  in the case that the base URL is unchanged, but the fragment
specifier (following the "#") changes, NN 4.73 does not communicate the new
URL+fragment to the plugin.  WebCGM and SVG both use object addressing syntax of
the general form:  <baseURL>#<objectID>.  Therefore one cannot, for example from
HTML, successfully consecutively address two different objects within the same
picture in a WebCGM or SVG content.  -Lofton.

Comment 28

[Kevin McCluskey (gone)]

Ok, [e-mail] and I just looked at this problem.

We believe the solution is to go to the document and retrieve the src attribute
instead of using the URL passed to the plugin. On 6.x this can be done using the
new plugin API. you can retrieve the src attribute in it's raw form from the
document using a GetAttribute call.

For info on the new plugin API look at
http://www.mozilla.org/docs/plugin.html#nsiplugintaginfo

The nsIPluginTagInfo has a GetAttribute method that you should be able to use to
get the src attribute's content which will include the raw URL with.

For 4.x based browsers the solution is similiar. Instead of using the new plugin
API you will have to use LiveConnect to retrieve the src attribute from the
document.

Comment 29

[Kevin McCluskey (gone)]

Here is the URL for documentation related to liveconnect plugins in 4.x
http://home.netscape.com/eng/mozilla/3.0/handbook/plugins/
You will need to create a Java class to get the src attribute out of the
document. Using LiveConnect you can access the JavaClass from your plugin.

There is also an adapter which allows you to write plugins with are compatible
with both 4.x and 6.0.

Comment 30

[Peter Lubczynski]

I think you are talking about named anchor support (url#namedanchor)?

Perhaps it is byte range support looking for, something which Acrobat uses. 
Please see bug 53353.

What does the spec say if anything about passing these along to plugins?

Chrisn, what is the current status with the CGM plugin?

Comment 31

[Peter Lubczynski]

I think we are getting offtrack. I just took a closer look at this bug, and
here's the recap of the problem:

Mozilla seems to think when clicking on an anchor link element, that:
src=http://host.domain.tld/myplugin.cgm
is the same as
src=http://host.domain.tld/myplugin.cgm#fragment

The expected result is the complete url being passed off to the plugin.
Clearing milestone for re-triage and rephrasing the summary from:
# fragments stripped off, so CGM plugin and others do not work with N6.

So, this goes down the full-page plugin route, so I wonder how
nsPluginViewer.cpp is getting the URL. I'd break in the debugger, but I can't
find a CGM plugin to reproduce. The one I downloaded is not working with Mozilla.

Could someone point me where I can download a CGM plugin that works with
Mozilla? Thanks!

Comment 32

[Peter Lubczynski]

-->peterl

Comment 33

[Peter Lubczynski]

Closing this bug out by marking WORKSFORME. 

Tested using the WebCGM plugin from:
http://www.ematek.com/downmweb.htm 
As far as I can tell, the plugin now works fine in Mozilla and I am able to
verify that all # fragments do get sent. We reload for each # request correctly.
This is not a bug Mozilla or Netscape 6.1, however it still is a bug in Nav 4.x.
However, this is a Mozilla-only bugbase.

Also note that with fixing bug 90256, full-page plugins will be scriptable as
their embedded counterparts which should provide greater flexibility.

Comment 34

[shrirang khanzode]

verifed wfm.