need a generic Menu Overlay for extension use




15 years ago
9 years ago


(Reporter: Callek, Unassigned)


Bug Flags:
blocking0.9 -
blocking-aviary1.0PR -
blocking-aviary1.0 -

Firefox Tracking Flags

(Not tracked)



(2 attachments)



15 years ago
There is a need for a generic menu overlay for extension use, because the dtd
system breaks if dtd's are missing, though contents.rdf can dynamically include
an overlay even if missing, without a problem.

(See upcoming attachment of an irc convo explaining in detail)

Comment 1

15 years ago
Created attachment 150251 [details]
IRC log description

Comment 2

15 years ago
Created attachment 150252 [details]
Work in progress

too tired to finish atm, will finish before days end "EST/EDT" (whichever it is

Comment 3

15 years ago
Marking blocking 0.9 as per mine and mconnor's talk.  Ben please decide on if
this is do-able.
Flags: blocking0.9+

Comment 4

15 years ago
decided to add calendar keyword, since thats where my head is on this Bug, if
anyone disagree's remove it.
Keywords: calendar

Comment 5

15 years ago
Comment on attachment 150252 [details]
Work in progress

Looks like a copy of, although you miss some recent changes
like the switch to Edit-Preferences on Unix.

Can't you #include that file, like browser.xul does?

Comment 6

15 years ago
You can't dynamically #include files, it's a build-time thing not a run-time
thing. That's why overlays exist.

I agree that the toolkit (heading towards 2.0) needs a dynamic overlay for basic
menu functions. However, I'm very confused why this is affecting 0.9.  The
new-toolkit calendar app is sunbird, not a firefox extension, right?

This is *not* blocking 0.9.
Flags: blocking0.9+ → blocking0.9-
calendar exist as stantalone app, sunbird.
but there also is an xpi version. one xpi for seamonkey, ff and tb.

As it is, calendar isn't installable under firefox.

Comment 8

15 years ago
If the overlay doesnt exist, it will need to be packaged twice, (headache for 
devs and for users, ending up grabbing the wrong one [even more than current] 
since we would need to include the dtd once for each format of calendar.

This should not and does not (iirc) affect standalone sunbird, but does affect 
FF 0.9 (and 1.0) for that matter.

Though I think #include would be possible I cannot do it as the #included files 
do not have id set on most elements, have dependancies on scripts (which I plan 
to, at least for the most part pull out) these id's will match their SM 
counterparts, though I will not be adding in any non-FF already defined stuff, 
this overlay should exist in browser.jar (I think it is) along with browser.xul 
and such files.  So that we can include it via a dynamic overlay (contents.rdf) 
and have it work in the same xpi for both FF, and SM [as well as TB I assume, 
though I havent looked over that way yet]

Please reconsider blocking 0.9 status Ben.

Comment 9

15 years ago
requesting blocking 1.0 on this, though still request that 0.9's status be
reconsidered (even though this was quite a late breaking request)
Flags: blocking1.0?
Flags: blocking-aviary1.0RC1-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-

Comment 10

14 years ago
Blake/Ben, should this be a wontfix? or should I still consider it a to-do?


13 years ago
Assignee: firefox → nobody
QA Contact: bugzilla → menus

Comment 11

9 years ago
Worked on this last 6 years ago, a lot has changed.

I don't think it is needed anymore, nor do I think it would be accepted at this point.
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.