Closed Bug 873102 Opened 11 years ago Closed 11 years ago

Deprecate the addon-page module

Categories

(Add-on SDK Graveyard :: General, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mossop, Assigned: zer0)

References

Details

Attachments

(1 file)

UX have decided that we will no longer be hiding chrome for content pages like about:addons and the australis team are removing functionality for it. So I guess we need to follow suit and deprecate the addon-page module. Thankfully this is easy, addon-page has no API as such, we just need to make requiring it a no-op (with a deprecation message) and we're done. Oh and remove the tests for it.
Blocks: 812864
Blocks: 804051
Blocks: 845502
Blocks: 850449
Blocks: 829845
Blocks: 868830
Blocks: 834913
No API, for sure, but it offers the capability to create a tab without the Awesome Bar, Search Bar and Bookmarks Toolbar which is perfect to display some information on add-on install. These capabilities are not possible using tabs.open or I am missed something...
(In reply to Marc Chevrier from comment #1) > No API, for sure, but it offers the capability to create a tab without the > Awesome Bar, Search Bar and Bookmarks Toolbar which is perfect to display > some information on add-on install. > > These capabilities are not possible using tabs.open or I am missed > something... You aren't missing anything. The problem is that with the new australis theme that is coming for Firefox this would mean hiding critical pieces of Firefox's UI, like the main menu.
I understand your concerns but is it planned to offer some alternative way to create a tab with unwanted elements ? For example, it will be perfect to extend tabs.open with options specifying which elements must be displayed or hidden.
(In reply to Marc Chevrier from comment #3) > I understand your concerns but is it planned to offer some alternative way > to create a tab with unwanted elements ? > > For example, it will be perfect to extend tabs.open with options specifying > which elements must be displayed or hidden. I'm not sure I really see a sane way to do that, even if you hide say the location bar it doesn't gain you any screen real estate and at that point is there any reason to do it?
The idea is to be able to display, in a tab, an informational message coming from an html which is part of the add-on internals so displaying url of bookmarks make no sense in this case.
Marc, if hiding pieces of the UI is important to you, you should file a new bug for that.
Priority: -- → P1
Assignee: nobody → zer0
Pointer to Github pull-request
Comment on attachment 755791 [details] Pointer to Github pull request: https://github.com/mozilla/addon-sdk/pull/1013 As discussed, I just added the deprecation message and keep the functionality, in order to give time to the developers to deal with it. Maybe we could also uplift to Firefox 23. I was wondering: Do we keep this bug open until we remove the functionality, or we'll open a new bug for that?
Attachment #755791 - Flags: review?(dtownsend+bugmail)
(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #8) > Comment on attachment 755791 [details] > Pointer to Github pull request: > https://github.com/mozilla/addon-sdk/pull/1013 > > As discussed, I just added the deprecation message and keep the > functionality, in order to give time to the developers to deal with it. > Maybe we could also uplift to Firefox 23. > > I was wondering: Do we keep this bug open until we remove the functionality, > or we'll open a new bug for that? Apologies for the driveby: on the UX branch, these tests currently fail, all the time, because the functionality is already gone. Would it be possible to remove the tests and only check the deprecation message?
(In reply to :Gijs Kruitbosch from comment #9) > (In reply to Matteo Ferretti [:matteo] [:zer0] from comment #8) > > Comment on attachment 755791 [details] > > Pointer to Github pull request: > > https://github.com/mozilla/addon-sdk/pull/1013 > > > > As discussed, I just added the deprecation message and keep the > > functionality, in order to give time to the developers to deal with it. > > Maybe we could also uplift to Firefox 23. > > > > I was wondering: Do we keep this bug open until we remove the functionality, > > or we'll open a new bug for that? > > Apologies for the driveby: on the UX branch, these tests currently fail, all > the time, because the functionality is already gone. Would it be possible to > remove the tests and only check the deprecation message? You can do that on your UX branch if you like. Given that the functionality still exists in m-c and that is where we merge to we will be keeping the tests around until we remove the functionality
Attachment #755791 - Flags: review?(dtownsend+bugmail) → review+
Commits pushed to master at https://github.com/mozilla/addon-sdk https://github.com/mozilla/addon-sdk/commit/759c4a533457f2ff22b401b691d0173ce6d1dc74 Bug 873102 - Deprecate the addon-page module - Added deprecation message - Update unit test to check deprecation message https://github.com/mozilla/addon-sdk/commit/338ffdbadb7e5aef1cb8c0d65e6d9886b34f61f8 Merge pull request #1013 from ZER0/addon-page/873102 fix Bug 873102 - Deprecate the addon-page module r=@Mossop
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: