On Chromium based browsers, the webNavigation API supports a processId property which identifies in which process the frame is rendered, every webNavigation event contains this property and it is a mandatory detail in the webNAvigation.getFrame API method. Our implementation of the webNavigation API doesn't currently support this processId field, and it is marked unsupported (and not populated) in all the webNavigation events. As our implementation doesn't need any processId to identify and interact with the process which contains a defined frame, it is marked as optional in the webNavigation.getFrame API method to simplify the creation of add-ons which make use of this API across browsers.
Since this bug was filed, the Chrome changed to deprecate processid when calling getFrame(), and I can't find any other great need for it, so this might not be as important as when first triaged.. https://developer.chrome.com/extensions/webNavigation#method-getFrame
(In reply to Tomislav Jovanovic :zombie from comment #1) > Since this bug was filed, the Chrome changed to deprecate processid when > calling getFrame(), and I can't find any other great need for it, so this > might not be as important as when first triaged.. > > https://developer.chrome.com/extensions/webNavigation#method-getFrame Thanks a lot for reporting this finding! If it is now deprecated on Chrome, it doesn't make any sense to keep this issue goal as it is. Given that processId property is already optional in the getFrame() method, the only additional change related to it can be to print a warning in the console that inform the developer that the processId is ignored and, as a deprecated feature, it is not going to be implemented (and it should not be used). I'm updating the issue summary accordingly and, given that this change is even less critical then it was, I'm setting its priority to P5.