Closed Bug 300542 Opened 19 years ago Closed 14 years ago

LXR badly munges some URIS

Categories

(Webtools Graveyard :: MXR, defect)

Product:
Webtools Graveyard
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bzbarsky, Assigned: timeless)

Details

STEPS TO REPRODUCE:
1)  Load
http://lxr.mozilla.org/seamonkey/source/layout/svg/base/src/resources/content/svgBindings.xml#50
2)  Look at line 50.

EXPECTED RESULTS: (based on ?raw=1):

    <resources>
      <stylesheet src="data:text/css,@namespace
url('http://www.w3.org/1999/xlink'); xlink { -moz-binding:
url('chrome://global/content/svg/svgBindings.xml#xlink'); }"/>
    </resources>

ACTUAL RESULTS:

 49     <resources>
 50       http://www.w3.org/1999/xlink'); xlink { -moz-binding:
url('chrome://global/content/svg/svgBindings.xml#xlink'); }"/"><stylesheet
src="data:text/css,@namespace url('http://www.w3.org/1999/xlink'); xlink {
-moz-binding: url('chrome://global/content/svg/svgBindings.xml#xlink'); }"/>
 51     </resources>

Note that a big chunk of line 50 at the beginning is misplaced and that some of
the content there is doubled.
Mass reassign of open bugs for chase@mozilla.org to build@mozilla-org.bugs.
Assignee: chase → build
QA Contact: timeless → lxr
Reassigning all LXR bugs assigned to build@mozilla-org.bugs to the default LXR owner (sorry Bear!)

We aren't actively working on these (if that's wrong, please reassign to yourself/a real person).
Assignee: build → bear
QA Contact: lxr → timeless
Version: Trunk → other
QA Contact: timeless → lxr
fwiw, at this point mxr is treating xml finds as containers for js and so it sees 'http' as an identifier which it knows is defined in places. the result is that instead of getting links to urls you get lots of identifier links.

the rendered text isn't corrupt anymore (slight win)

http://mxr.mozilla.org/mozilla-central/source/mobile/chrome/content/content.css#240

240   -moz-binding: url("chrome://browser/content/bindings.xml#select-button");

the url is magically linkified usefully

for xul files, mxr doesn't treat them as code sources, so you get:
http://mxr.mozilla.org/mozilla-central/source/xpfe/components/autocomplete/test/autocomplete_test.xul#8

8         xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
9         xmlns:nc="http://home.netscape.com/NC-rdf#"
10                 orient="vertical"

with things properly linked

an rdf file with a hash:
http://mxr.mozilla.org/mozilla-central/source/xulrunner/app/profile/extensions/Extensions.rdf#3

3 <RDF xmlns:em="http://www.mozilla.org/2004/em-rdf#"
4      xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

a xul file with hash-text:
http://mxr.mozilla.org/mozilla-central/source/rdf/tests/dsds/DataSourceViewer.xul#13

13   containment="http://home.netscape.com/NC-rdf#child">

a xul file with two links:

http://mxr.mozilla.org/mozilla-central/source/layout/tables/crashtests/322779-1.xul#2

2 <window xmlns:html="http://www.w3.org/1999/xhtml" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

http://mxr.mozilla.org/mozilla-central/source/layout/xul/base/src/crashtests/menulist-focused.xhtml#1

1 <html xmlns="http://www.w3.org/1999/xhtml" xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

I think I'm going to resolve this bug as fixed, since i believe the primary complaint is that the visible text doesn't match the underlying source.

---
I do hope to at some point fix the parser so that it can handle both Identifier and Raw contexts - or at least teach the parser to recognize urls.

the basic parser code is:
http://mxr.mozilla.org/webtools-central/source/mxr/lib/SimpleParse.pm
and it's controlled by a set of rules

http://mxr.mozilla.org/webtools-central/source/mxr/lib/LXR/Common.pm#333
Assignee: bear → timeless
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.