Closed Bug 1154662 Opened 9 years ago Closed 8 years ago

CategoryManagerInterposition should cover get/add/deleteCategoryEntry

Categories

(Core :: DOM: Content Processes, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
e10s + ---

People

(Reporter: gkrizsanits, Unassigned)

References

Details

tracking-e10s: --- → ?
Is this addons specific?
Flags: needinfo?(gkrizsanits)
(In reply to Jim Mathies [:jimm] from comment #1)
> Is this addons specific?

Yes.
Flags: needinfo?(gkrizsanits)
Blocks: e10s-addons
did Bug 982319 Comment 22 fix the issue?  if not i'll follow up with DOM team.  thx
Flags: needinfo?(gkrizsanits)
(In reply to :shell escalante from comment #3)
> did Bug 982319 Comment 22 fix the issue?  if not i'll follow up with DOM
> team.  thx

No bug 982319 was about fixing another problem. This bug has not been addressed.
Flags: needinfo?(gkrizsanits)
Doing some searches in dxr show the number of addons at:

getCategoryEntry 92
addCategoryEntry 1003
deleteCategoryEntry 596

That does seem quite a large number of add-ons, but its not obvious the impact of this and if those add-ons will break. From that I can't determine this bugs priority, I'm not sure if Gabor has feedback.
Hi Gabor, Based on Andy's comment 5 - did you have anything to add?
Flags: needinfo?(gkrizsanits)
I might make sense to do some grepping here but just by reading through the first few pages of dxr output I see these categories the most:

xpcom-startup
xpcom-shutdown
command-line-handler
app-startup
profile-after-change

content-policy
simple-content-policy
ext-to-type-mapping

net-channel-event-sinks

The first group looks like that should happen in the parent anyway, so I don't think anything will be broken there.

For the second group I expect breakage, but the number of add-ons for those seems like a lot smaller. Now we have to decide if using shims here is a lot better than just breaking these add-ons. Some of these add-ons might already execute their code in the content process which they should do and then we're golden. For the rest of them if we make this work with shims we still might end up with something so slow that will be useless in the end (because of CPOWs + shims). Based on the numbers I'm leaning toward won't fixing it.

And there is net-channel-event-sinks which I think it's important and I'm not sure on which side it should run but the add-ons using it (https everywhere, noscript, avira) probably fixed it already if they had to so I wouldn't bother about that either.

All in all I don't think this is a high prio, might be even a won't fix in the end. Mentioning it in the docs is probably important.
Flags: needinfo?(gkrizsanits)
xpcom-startup happens in the content process, I think. (xpcom-shutdown would happen, too, but we exit(0) before then in opt builds.)
(In reply to Andrew McCreight [:mccr8] from comment #8)
> xpcom-startup happens in the content process, I think. (xpcom-shutdown would
> happen, too, but we exit(0) before then in opt builds.)

Are you sure? I would think that since we init xpcom in both processes we notify the observers in both process... Which would be OK, since the content process hardly want to be notified when the parent processes xpcom is inited... But I just _assume_ this, cannot find the related code somehow, could you point me to it?
Flags: needinfo?(continuation)
Ah, well, I admit I don't understand the broader context of this bug, so you should probably just ignore me. (And reading that other bug I still don't understand it.)  I was only remarking specifically on whether the observer service does xpcom-startup in the content process.
Flags: needinfo?(continuation)
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.