1111348 - [e10s] tab contentType attribute is undefined for tab opened from startup

Status: RESOLVED DUPLICATE of bug 1017751

(Add-on SDK Graveyard :: General, defect)

Description

[Marc Chevrier]

Attachment: Add-on SDK tab.contentType bug

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141125180439

Steps to reproduce:

Add-on based on Add-on SDK which (see attachment), during startup, open a tab (sdk/tabs.open) and catch 'activate' event: tab passed to 'activate' event handler has contentType attribute undefined. This only occurs in e10s mode (FF37.0a1 21014/12/14)


Actual results:

display in console value 'undefined' for contentType tab attribute


Expected results:

Display in console value 'text/html' for contentType tab attribute

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Hey zombie, is this an SDK bug, or do you think the problem is in Fx's start-up code for e10s?

Comment 2

[Tomislav Jovanovic :zombie]

so, this is not technically a bug, but a race condition, made (more) apparent by e10s.

there is not guarantee that tab's properties (like .url, or .contentType in this case) are available by the time the 'activate' event is fired. this is mostly (always?) true with a single-process firefox, but with e10s, UI updates (like the 'activate' events) are completely divorced from page loading.

i even ran into very similar issue in bug 1017751, and as a result, we have all this documented:
https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/tabs#activate_2

Marc, is this explanation satisfactory? can you please confirm this is actually the issue you are seeing? if so, i think we can mark this duplicate of bug 1017751.

Comment 3

[Marc Chevrier]

Yes, explanation given in bug 1017751 matches perfectly with my problem. So I marks this bug as a duplicate of bug 1017751.

Thank you for your help.