Closed Bug 651590 Opened 13 years ago Closed 13 years ago

worker tab property pointing at activeTab, not page-mod tab

Categories

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

x86
Windows XP
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: cutler.jeremy, Assigned: irakli)

Details

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0

I create a pageMod whose message handler uses the worker reference to post messages to the correct tab. In addition, the message handler should be attaching new page-mods to that tab, however it always reverts to attaching these new page-mods to the active tab instead of the tab that send the message.



Reproducible: Always

Steps to Reproduce:
main.js
=======

function handleMessage(message, myWorker) {

   ...

   myWorker.postMessage(...); //this works correctly

   ...

   myWorker.tab.attach({
      contentScriptWhen: 'ready',
      contentScriptFile: theScripts,
      onMessage: function onMessage(data) {
         handleMessage(data, this);
      }
   });
}

pageMod.PageMod({
   include: ["http://www.tumblr.com/*"],
   contentScriptWhen: 'ready',
   contentScriptFile: [data.url("common/whoami.js")],
   onAttach: function onAttach(worker) {
      worker.on('message', function(data) {
         handleMessage(data, this);
      });
   }
});
Actual Results:  
The scripts in theScripts are loaded into whatever the active tab is when the attach method is executed, instead of the tab that actually corresponds to the myWorker worker object.

Expected Results:  
The scripts in theScripts should executed in the tab that sent the message. myWorker.tab should return the tab corresponding to the page-worker created in the page-mod instantiation.
Wherever I use the term page-worker, please note, instead, that I mean content/worker
In addition, if I change the onAttach function to:

onAttach: function onAttach(worker) {
   console.log(worker.url);
   console.log(worker.tab.title);
}

and then open a new tab in the background (which is, itself affected by the page-mod), the console output gives the title of the current tab, not the new one I've opened in the background. The url, however, is correct!
Irakli: can you take a look at this?
Priority: -- → P1
Target Milestone: --- → 1.0
Assignee: nobody → rFobic
Comment on attachment 532944 [details]
Pointer to Github pull request: https://github.com/mozilla/addon-sdk/pull/167

Jeremy I was not able to reproduce this bug. It's either:

1. Bug was fixed by other related change.
2. I misunderstood described problem.

I have created pull request containing a test with a scenario described. Can you please verify that it actually covers the error you've experienced ? If not maybe you can contribute by modifying the test so that it covers your described scenario. Finally can you please let us know if you're still able to reproduce this bug.

Thanks!

P.S.: I'd like to land this test case regardless whether we can reproduce this bug or not.
Irakli

I just recently updated from 1.0b4 to 1.0b5, and it looks like the bug was fixed, as my test now seems to work.

I haven't tried the testcase you provided with 1.0b4, but it certainly appears to me that it would exercise the issue I had, seeing that there is an attempt to attach a worker to a created tab. This would only hit the bug (on 1.0b4) if the new opened tab is not the active tab at the time that the 'attach' call is made.
Thanks Jeremy! I'm glad it's fixed!
Attachment #532944 - Flags: review?(myk)
Gracias
Comment on attachment 533652 [details]
plataforma trabajo alumna uned

qué dolor de cabeza. ensayo y error, error y ensayo ....
Attachment #532944 - Flags: review?(myk) → review+
Comment on attachment 533652 [details]
plataforma trabajo alumna uned

Gilma: it isn't clear what you were trying to do by attaching this file, but it doesn't appear to be related to this bug, thus I am marking the attachment as obsolete.  If you explain what you were trying to do, one of us can help you figure out how to do it.  I have also cc:ed a project participant who understands Spanish and can help translate if needed.
Attachment #533652 - Attachment is obsolete: true
Gilma: Que es lo que estás intentando hacer? Ni siquiera yo lo entiendo muy bien. De todos modos es considerado respetuoso escribir en bugzilla en inglés, si todos escribieran en su idioma natal nadie se entenderia ;)

Myk: Sorry about the Spanish. I asked her what's she trying to do, because even I don't understand.
https://github.com/mozilla/addon-sdk/commit/1985c598156c47e8760b6cccc42e7862775fccbe
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Reopening, it looks like this test fails on build bot:
http://tinderbox.mozilla.org/showlog.cgi?log=Jetpack/1306277625.1306277799.19307.gz&fulltext=1#err35

I'll investigate, but any ideas on how to reproduce this are more then welcome!
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: FIXED → ---
So I managed to reproduce some issues on latest nightly build. Error looked different but was in the same file so it could be related. Unencoded data uris in test were behaving unexpectedly that caused some issues in the following tests. I have updated pull request to add this change, but have no idea if that will solve issue we see on bulidbots.
Comment on attachment 535024 [details]
Pointer to Github pull request: https://github.com/mozilla/addon-sdk/pull/175

talked on irc. doing this to see if it affects buildbot failures, r=me.
Attachment #535024 - Flags: review?(dietrich) → review+
Looks like build bots are happy now except the ones that have some unrelated issues, so I'm closing this one!
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: