Set the website as the default handler if it registers as a content handler

RESOLVED DUPLICATE of bug 1270416

Status

()

Firefox
File Handling
RESOLVED DUPLICATE of bug 1270416
2 years ago
a year ago

People

(Reporter: edenchuang, Assigned: WillWang)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Set the add-on or plugin as the default handler after installation if it registers as a content handler.
(Reporter)

Updated

2 years ago
Blocks: 1270402
(Assignee)

Updated

2 years ago
Assignee: nobody → wiwang
(Assignee)

Comment 1

2 years ago
The current UX spec[1] is still under refinement, I'm trying some modifications before the spec is quite stable.

[1] https://mozilla.invisionapp.com/share/4Y6ZZH1E8#/screens/156737028
(Assignee)

Comment 2

2 years ago
Today, The UX discussion shows the handler should be set as default after installation, however we will implement this after the UX spec pass sort of sign-off/confirmation.
(Assignee)

Comment 3

2 years ago
Created attachment 8766749 [details] [diff] [review]
bug1270419.patch

This patch set the add-on which was just installed as the default content handler in the application panel.

Some observed facts:
- After add-on installation, API registerContentHandler() will be invoked once Firefox restart.
- For above API, Firefox currently only support feed types [1] 


[1]
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerContentHandler
(Assignee)

Comment 5

2 years ago
Content handling part of UX spec is currently under discussion for better balance of security and UI, the patch will be sent to review process after the discussion are done.
(Assignee)

Comment 6

2 years ago
Hi Bryant,

Could you kindly send a feedback here once UX spec decides whether we should set the handler as default or only as a option in list like we did before?

Thanks for your works and info!
Flags: needinfo?(bmao)
(Assignee)

Comment 7

2 years ago
Revise bug title to clearly distinguish the ambiguous terminology and state bug scope.

- Terminology clarification:
Add-ons is not equal to extension. 
Add-ons include extension, plugin, theme(appearance) and so on.

- Bug scope: 
Per offline discussion with UX member, we decide to remove the new design for plugin and extension, 
which means installation of these two type of add-ons will not set themselves as default handler.
In the latest UX design, only the website(webapp) will set it as default handler if it calls registerContentHandler().
Summary: Set the add-on or plugin as the default handler after installation if it registers as a content handler → Set the website as the default handler if it registers as a content handler

Updated

2 years ago
Whiteboard: [CHE-MVP]

Comment 8

2 years ago
This bug is shown in Triage dashboard.
I believe Bryant is working on it.
Keep NI/monitoring.

Comment 9

2 years ago
Hi, Bryant,

I might miss something new.
Are we working on this? Any update?
Flags: needinfo?(bmao)
(Reporter)

Comment 10

2 years ago
Hi William

we still work on this bug. But this bug is too similar with the bug 1270416, I would like merge these two bugs into one. Because discussions are all tracked on bug 1270416, so I will set this bug as duplicate.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(bmao)
Resolution: --- → DUPLICATE
Duplicate of bug: 1270416

Comment 11

2 years ago
(In reply to Eden Chuang[:edenchuang] from comment #10)
> Hi William
> 
> we still work on this bug. But this bug is too similar with the bug 1270416,
> I would like merge these two bugs into one. Because discussions are all
> tracked on bug 1270416, so I will set this bug as duplicate.
> 
> *** This bug has been marked as a duplicate of bug 1270416 ***

No worries. This was a reminder because I saw this bug was in triage dashboard.
Thank you, Eden! :)

Updated

a year ago
Whiteboard: [CHE-MVP]
You need to log in before you can comment on or make changes to this bug.