Should we go with the approach from bug 1346004, we probably also want some facility to move a tab into a different group. We also need to trigger appropriate notifications, so e.g. the tabs tray can handle a tab changing it's type to/from a browsing-type tab.

Comment on attachment 8853347 [details] Bug 1348686 - WIP , just a begining of the type change process https://reviewboard.mozilla.org/r/125460/#review128234 ::: mobile/android/base/java/org/mozilla/gecko/Tab.java:778 (Diff revision 1) > + public void setType(TabType type) { > + if (mType != type) { > + mType = type; > + final GeckoBundle data = new GeckoBundle(1); > + data.putInt("id", mId); > + // TODO: 3/31/17 Not sure what to send here. If it's Tab:Load then we should make the data No need to shoehorn this into an existing message type if nothing suitable is available. Just look at the [the amount of work browser.js does for Tab:Load](https://dxr.mozilla.org/mozilla-central/rev/8df9fabf2587b7020889755acb9e75b664fe13cf/mobile/android/chrome/content/browser.js#1852). Your doubts are correct - you don't want to trigger all this just for changing the type. Just create a new message type (Tab:TypeChanged, or whatever sounds good) and handle that in browser.js to do what is necessary (updating the type on the tab object and notifying the session store). Tab:Selected is a good example of how this can look like.

Not blocking standalone mode, this is more relevant for customtabs afaik

I don't think we really need this for the first release of custom tabs, but we should look into it later.

Sorry I'm fully booked by other tasks. Anyone who is interested in this please take it. Or I'll come back when my current project ends.

No longer applicable with the switch to Geckoview-based custom tabs and web apps.