Likely duplicates https://bugs.chromium.org/p/chromium/issues/detail?id=582744 but I submitted new, since 582744 was opened 1.5 years ago and not resolved yet

Same issue affects browser_action pages too (and probably all other pages with tabId === -1)

 Issue 759473  has been merged into this issue.

@sirianru-- Thanks for reporting the issue. Could you also please provide the sample HTML file or extension to reproduce the issue. That would help us to test and triage the issue further.

Thanks in advance.

[mac bug triage]

rdevlin.cronin@	perhaps you can help triage this (and issue 582744) since it hasn't moved in a while. 

Hmm, interesting.  Technically, this *is* documented behavior:
https://developer.chrome.com/extensions/runtime#type-MessageSender

frameId: The frame that opened the connection. 0 for top-level frames, positive for child frames. This will only be set when tab is set.
tab: The tabs.Tab which opened the connection, if any. This property will only be present when the connection was opened from a tab (including content scripts), and only if the receiver is an extension, not an app.

So |frameId| only exists if |tab| exists, and |tab| only exists if it was a tab that sent the message, and in this case, it's not a tab sending the message (since the background page isn't a tab).

That said, I don't see any reason that frameId has to be linked to |tab| existing - we should have the frame id in any case.

Rob, it looks like you added this property back in revision 248d6a8456fdf67fa11be00e35105642f1871a9b; was there a reason to only include it when tab existed?

I've created extension example on github. 
https://github.com/sirian/chrome-issue-759474

In background page you will see log like

> webRequest sub_frame tabId: -1, frameId: 666
> webRequest other tabId: -1, frameId: 666
> onMessage {id: "glcgkmjooeahdmmadodabpkgdlndjebn", url: "https://example.org/"}

so frameId is exist and exposed at webRequest API. But not exposed at messaging API

> Rob, it looks like you added this property back in revision 248d6a8456fdf67fa11be00e35105642f1871a9b; was there a reason to only include it when tab existed?

At the time, the "frameId" was based on the routing ID, which was only unique per rendering process, and hence required a tab ID to uniquely identify a frame. When out-of-process frames started to become a thing, we switched to FrameTreeNode IDs, which is unique across all processes ( bug 432875 ).

I did intentionally did not document that frame IDs can uniquely identify frames, to allow the implementation to revert to non-unique IDs. However, it seems that the "frame ID" will continue to be globally unique since there is no reason to have another implementation. Moreover, the "frame IDs" in Firefox's independently developed WebExtensions API is also (statistically) unique across processes. Hence it is likely that the IDs will always be unique.

I think that it's OK to include frameId in a message from the background page.

When we do that, we should also consider allowing certain tab APIs to be used with tab ID "-1" and frameId, e.g.
chrome.tabs.connect
chrome.tabs.sendMessage
chrome.tabs.executeScript
chrome.tabs.insertCSS

Before supporting that, we need to check whether we really want to allow "-1" to be used for valid destinations, or whether we want to introduce a new tab ID, e.g. "-3" for "contexts that are not part of a tab, but that can contain frames."


> so frameId is exist and exposed at webRequest API. But not exposed at messaging API

in webRequest, the ExtensionApiFrameIdMap is used, which does not "ignore" frame tree node IDs for missing tabIDs:
https://chromium.googlesource.com/chromium/src/+/ee78727e1b88b5cd3310fc09f5be55c853ac8e37/extensions/browser/extension_api_frame_id_map.cc#167
https://chromium.googlesource.com/chromium/src/+/ee78727e1b88b5cd3310fc09f5be55c853ac8e37/extensions/browser/extension_api_frame_id_map.cc#358
The frameId provider does not take the (non-existence) of tabId into account either:
https://chromium.googlesource.com/chromium/src/+/ee78727e1b88b5cd3310fc09f5be55c853ac8e37/extensions/browser/extension_api_frame_id_map.cc#101

Whereas in extension messaging, the frameId is only set when the tabId is set:
https://chromium.googlesource.com/chromium/src/+/21f6df2a9bbb8c7bc60186c2ae1792b8361e1c5d/extensions/browser/api/messaging/message_service.cc#252

Mac triage: assigning to rdevlin.cronin@ for further triage per #10.

I think this would be a good one for dbertoni@ to tackle.  I think it does make sense to include frameId on all messages.

As a first step, I'd say we should just have those events include the frameId.  I like Rob's idea of potentially using frameId more broadly (and exercising its uniqueness), but I think that probably warrants a separate discussion/bug.

Any news? Or this had sunk into oblivion like https://bugs.chromium.org/p/chromium/issues/detail?id=582744 ?)