Closed Bug 251011 Opened 21 years ago Closed 21 years ago

Updated Extension: Link Toolbar

Categories

(addons.mozilla.org Graveyard :: Public Pages, defect)

Product:
addons.mozilla.org Graveyard
Component:
Public Pages
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: cody, Assigned: Bugzilla-alanjstrBugs)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2 A new, Firefox 0.9-compatible version of the Link Toolbar extension, by Chris 'CDN' Neale and Stephen Clavering, is available at the Extension Room entry linked above. All the information necessary for Mozilla Update-- description, home page, etc.-- is present at that URL. I'm filing this on behalf of CDN, who responded that he was "not going to spend time getting the Link Toolbar listed on update.mozilla.org". Reproducible: Always Steps to Reproduce:
Assignee: psychoticwolf → 9quawbieby0001
Status: UNCONFIRMED → NEW
Ever confirmed: true
What version is supposed to compatible? Our parser did not like install.rdf. The tags should have em: in them.
Status: NEW → ASSIGNED
Hm. Version 0.8 of Link Toolbar installed fine for me in Firefox 0.9.2, but you're right, the RDF isn't perfectly valid. I also noticed that the Unique ID doesn't follow the standard convention. Should I contact cdn or clav about this, possibly offering to create a compliant install.rdf?
If they are willing to have it listed, yes.
I've submitted a bug report and attached a compliant version of install.rdf.
Regarding comment 0 - no I didn't.
cdn: so are you saying you don't want it listed?
Mea culpa. It was clav who said that. My brain is not working today. :)
Regarding comment 1, if your parser can't cope with an install.rdf that uses different namespace prefixes (but the correct namespaces) then it is defective. Regarding comment 2, the RDF /is/ perfectly valid, though you are correct that the id is not a GUID. That is because the use of GUIDs is entirely without merit, as extensions can still conflict on chrome names even if they have different ids in their install.rdf. A real solution to this problem would be to use java-style package names or similar in both install.rdf and the various contents.rdf's.
Only standards that conform to the standard put forth by Ben will be accepted. A separate bug should be filed to handle the namespaces problem (we use some regex hacking)
(In reply to comment #9) > Only standards that conform to the standard put forth by Ben will be accepted. Only installs.rdf that conform to the standard put forth by Ben are being accepted at this time.
heh, the namespace "problem" is a moot point.. if you follow the extension manifest directions correctly.. this is looking like a wontfix bug. :-) particularly since the authors appear to be evanglizing with their extension manifest and not just making an extension.
Clav has a perfectly valid point. The parser should be a bit more flexible. Clav, would you be willing to correct the parser if it's ok with Wolf?
Reopen this when install.rdf meets our needs. Work on the parser should be filed as its own bug.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
Component: Update → Listings
Product: mozilla.org → Update
Version: other → unspecified
AMO BUGSPAM FOR COMPONENT MOVE AND DELETE (FILTER ME)
Component: Listings → Web Site
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.