When using WebExt messaging with Responsive Design Mode, message manager
messages traveling from content to parent such as "MessageChannel:Messages" are
received with `event.target` set to the <iframe mozbrowser> inside RDM that
hosts the content.
Here we change `getSender` processing for messages like this to also check HTML
iframes for related tabs, in addition to XUL elements as before.
MozReview-Commit-ID: 3qphe2W8jHM
This patch introduces two changes to the test:
1. It breaks apart the assertion that was combining three tests into individual assertions, so if this does
fail again in the future it will be easier to spot the actual problem.
2. It uses addTab and browserLoaded instead of openNewForegroundTab, which seems to allow the test to wait
long enough before starting the extension.
When I was able to reproduce the failure, after separating the assertions, I found the one that was failing
was the check that tab2.lastAccessed was less than the current time. I believe that the current time was being
recorded too soon, which is why I changed the test to not record the current time until after both tabs have
completed loading. This seems to fix the intermittent locally for me.
MozReview-Commit-ID: I3VoYODwjgz
This patch just forwards invocations of the bootstrap update() and
uninstall() methods to events that other parts of the WebExtension
framework can listen for. We have an existing event that fires while
an extension is being uninstalled. This event was named "uninstall"
but it gets renamed here to "onUninstalling" to disambiguate the two
events.
MozReview-Commit-ID: BIpIR8n9HBM
I spoke to Marco about this and it turns out the problem is due to using PlacesUtils.history.insertMany together with
PlacesTestUtils.visitsInDB. Calling the former to insert the visits and then immediately calling the latter to verify
them can result in the latter reading a snapshot of the places DB that is not up to date. The fix is to call
PlacesTestUtils.addVisits which will not return until everything is finished up and will therefore not cause
PlacesTestUtils.visitsInDB to possibly read an old snapshot.
MozReview-Commit-ID: GebqORQI0Co
When the New Tab page is opened, the browser object that is passed into the isArticleChangeListener
is not a valid browser from the perspective of tabbrowser.xml, so it is not able to find it in its
_tabForBrowser map. This causes undefined to be passed into tabManager.getWrapper(), which causes
the error.
This patch fixes this by not calling tabManager.getWrapper(), and subsequently firing the onUpdate
event, if the return value from gBrowser.getTabForBrowser() is undefined. Testing shows that that
is only the case when the New Tab page is opened, and that page is not, and is unlikely to be
readerable any time in the foreseeable future (confirmed on IRC), so ignoring this case in the
listener is acceptable.
MozReview-Commit-ID: D9LQRrPmCoU
It is helpful to have a slot which never has a token, so that the
absense of a token can be asserted in unit tests.
Add a third token that is always empty, and update a number of unit
tests to check for it.
MozReview-Commit-ID: 4apvRRhZJus
This applies the following changes:
- store a weak reference to the browser element in the WebNavigation.jsm Manager's map
of pending CreatedNavigationTarget messages
- when a CreatedNavigationTarget message is received from a sourceTab
for a created window that is not currently tracked in the map
(e.g. it has been immediately closed), the message received from the sourceTab
is not saved in the map of the pending CreatedNavigationTarget (and a message
is logged in the console to make easier to investigate issues related to discarded
CreatedNavigationTarget events).
- adds an additional assertion to the related test case to ensure that no CreatedNavigationTarget
message is still pending in the WebNavigation/jsm's Manager.
MozReview-Commit-ID: FijQ8IqiY8L
This changes fixes the regression introduced by Bug 1355120 and adds a new
test case which contains a browserAction popup which open and immediately
close a new window and ensure that the received onCreatedNavigationTarget
is the expected one.
MozReview-Commit-ID: JIcVCpBTpxj
It is helpful to have a slot which never has a token, so that the
absense of a token can be asserted in unit tests.
Add a third token that is always empty, and update a number of unit
tests to check for it.
MozReview-Commit-ID: 4apvRRhZJus
