remove support for Carbon NPAPI

RESOLVED FIXED in mozilla19

Status

()

Core
Plug-ins
RESOLVED FIXED
7 years ago
5 years ago

People

(Reporter: Josh Aas, Assigned: Josh Aas)

Tracking

Trunk
mozilla19
All
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

7 years ago
https://mail.mozilla.org/pipermail/plugin-futures/2010-June/000120.html

The Carbon event model is considered deprecated in Firefox 4 (Gecko 2.0.0) and we are planning to remove support for it entirely after Firefox 4. Its replacement is the Cocoa event model, introduced in Firefox 4 (Gecko 2.0.0). We are working with plugin vendors to make sure they are ready for this change.

Reasoning:

1. The Carbon event model is generally inferior to the Cocoa event model. It also isn't as well documented.

2. Our out-of-process plugin implementation does not support the Carbon event model and we want to require all plugins to run out of process by default. The Carbon event model was not designed with IPC in mind, the Cocoa event model was.

3. Maintaining multiple/duplicate event models in our code significantly increases complexity which results in slower development and QA, and ultimately lower quality.

4. We are moving towards x86_64 as our primary architecture for Mac OS X. Implementing Carbon NPAPI support in our x86_64 code may not be impossible but it would almost certainly be an unreasonable endeavor.

5. Removing support entirely is the ultimate form of deterrence for plugin vendors. We really don't want people shipping Carbon event model plugins after Firefox 4 is released.
(Assignee)

Comment 1

7 years ago
I think we need to keep Carbon NPAPI support so long as we support Mac OS X 10.5 so this probably won't happen for the release after Firefox 4.
(Assignee)

Updated

6 years ago
Assignee: joshmoz → nobody

Comment 2

5 years ago
FYI, in case parity is a factor in when this lands: Starting with Chrome 22, Mac Chrome will not support the Carbon event model (we're dropping it in parallel with the QuickDraw drawing model).

Comment 3

5 years ago
I should also explain the motivation: the *only* plugin that I'm aware of that uses CG+Carbon at this point is Garmin, and they have a 64-bit plugin using CG+Cocoa so anyone running Firefox in 64-bit mode wouldn't see any change. And since the plugin is broken now in Chrome (which I've communicated to them), I expect them to update at some point fairly soon to do event negotiation in 32-bit mode.

So it's likely that once bug 598401 lands there is essentially zero user impact to doing this too.
(Assignee)

Updated

5 years ago
QA Contact: joshmoz
(Assignee)

Updated

5 years ago
Blocks: 787510
Blocks: 790373
(Assignee)

Updated

5 years ago
Assignee: nobody → joshmoz
QA Contact: joshmoz
(Assignee)

Comment 4

5 years ago
Created attachment 670797 [details] [diff] [review]
fix v1.0

https://tbpl.mozilla.org/?tree=Try&rev=b735e738aae5
(Assignee)

Updated

5 years ago
Attachment #670797 - Flags: review?(smichaud)
Looks fine to me.

One small nit:

The definition of kFocusedChildViewTSMDocPropertyTag and the calls to TSMSetDocumentProperty() and TSMRemoveDocumentProperty() that surround the single remaining call to TSMProcessRawKeyEvent() are no longer needed.  They were used to pass information to code (in PluginTextInputHandler::HandleKeyUpEvent()) that your patch removes.
Attachment #670797 - Flags: review?(smichaud) → review+
(Assignee)

Comment 6

5 years ago
Also, if we want to do a phase two we can probably remove a lot more checks for the Cocoa event model since it is the only model we support now. I left a bunch of checks in to simplify the patch.
> One small nit:
>
> The definition of kFocusedChildViewTSMDocPropertyTag and the calls
> to TSMSetDocumentProperty() and TSMRemoveDocumentProperty() that
> surround the single remaining call to TSMProcessRawKeyEvent() are no
> longer needed.  They were used to pass information to code (in
> PluginTextInputHandler::HandleKeyUpEvent()) that your patch removes.

Oops.  I just double-checked and this is wrong.

kFocusedChildViewTSMDocPropertyTag is also checked in
PluginTextInputHandler::PluginKeyEventsHandler(), which your patch
doesn't remove.
(Assignee)

Comment 8

5 years ago
Another try server run with different platforms:

https://tbpl.mozilla.org/?tree=Try&rev=cfa1565942da
(Assignee)

Comment 9

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/faa749453ea4
https://hg.mozilla.org/mozilla-central/rev/faa749453ea4
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19

Updated

5 years ago
Blocks: 753251
Blocks: 850925
You need to log in before you can comment on or make changes to this bug.