"page-mod" checks requested URL, but not URL after redirect

RESOLVED FIXED

Status

Add-on SDK
General
P1
normal
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: John Nagle, Unassigned, Mentored)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928134238

Steps to reproduce:

In a "page-mod"-using add-on, used patterns which triggered on Google search result pages. 


Actual results:

The add-on fires on Google search result pages, but when the user clicks on a link to a search result, one which is redirected through a Google site, the add-on is run on the target non-Google page as well.


Expected results:

The URL matching patterns passed to PageMod's "include" parameter need to be checked AFTER redirection, not BEFORE redirection.
(Reporter)

Comment 1

6 years ago
It might be possible to exploit this bug as as a security hole.  An add-on can be induced to work on a page for which it is not intended.
Alex, can you look at this and see what's happening?
Assignee: nobody → poirot.alex
Priority: -- → P1
Target Milestone: --- → 1.3
(Reporter)

Comment 3

6 years ago
Looking at the code in PageModManager of page-mod.js:

  _onContentWindow: function _onContentWindow(domObj) {
    let window = HAS_DOCUMENT_ELEMENT_INSERTED ? domObj.defaultView : domObj;
    // XML documents don't have windows, and we don't yet support them.
    if (!window)
      return;
    for (let rule in RULES)
      if (RULES[rule].test(window.document.URL))
        this._emit(rule, window);
  },

The code looks reasonable. "window.document.URL" is supposed to be the final URL after redirection. But when does it become that? Is it possible for this code to execute before redirection is complete?  

Incidentally, note that if two rules match the same page, the "emit" is fired twice.  That probably wasn't intended.
(Reporter)

Comment 4

6 years ago
I'm not sure of this yet, but by adding logging in my code I'm starting to see what's happening.  It's weird.  

My add-on is running a content script on Google search result pages.  If I right-click on a link on one of those pages before the content script has finished running, and open a new window (not tab), sometimes the content script is run on the new window.  The new window has a completely different URL, and doesn't match the "include" parameter in the page-mod object. 

The SAME instance of the content script seems to be running on the new window; the content script's initialization code does not seem to be executed.  The log entries the content script makes at startup don't appear.  This should not be happening.  I now think the problem is not launching the page mod on the wrong URL; it's that somehow, a running page mod script continues to run on a new window to which it should not be attached.  It's unwanted cross-site scripting. 

This is timing dependent; I have trouble reproducing it.
(Reporter)

Comment 5

6 years ago
More info:

I've been able to do this running under the add-on SDK "cfx" program, and now I have some logging of my own. The same page-mod content script instance can be successively attached to two web pages if the user clicks at just the right time. Since that's never supposed to happen with the page-mod SDK, Bad Stuff ensues.  Here's some annotated logging of my own messages.  I generate a random instance number when the content script loads, and print "document.URL" and the instance number at several points. Sometimes, the URL changes even when the instance number doesn't.  

This seems to be associated with clicking a link on a page where a page-mod content script is still working.  

The content script involved runs periodically on the page, fired by window.setTimeout. It may be that when the user leaves a page, its content script events aren't closed out properly.

(All this worked just fine under Greasemonkey, incidentally.)

[10/26/2011 12:13 PM - Checking for one content script being connected to two pages.]=

[Here is a page being handled properly. There's a new instance number, and all the "Check of document.URL" messages have the same URL as
the one first seen when the instance of the content script loaded. So the 1-1 relationship between content script instance and page
is being properly maintained.]

info: Instance #564686584 start. prefs: {"searchpref":" 2","adpref":"2","verbosepref":false}  Include URLs: [".*(www\\.,|)google\\.com\\/search.*",".*news\\.google\\.com\\/.*",".*(www\\.,|)bing.com\\/search.*",".*search.yahoo.com\\/.*",".*(www\\.,|)blekko.com\\/ws\\/.*",".*(www\\.,|)duckduckgo\\.com\\/\\?q\\=.*"]
info: Page to be analyzed: http://www.google.com/search?q=wikipedia+harry+potter&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
...

info: Instance #564686584  check of document.URL: http://www.google.com/search?q=wikipedia+harry+potter&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
info: Instance #564686584  check of document.URL: http://www.google.com/search?q=wikipedia+harry+potter&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

[Here's the beginning of the analysis of a new page. Note the instance number, set when the content script loads.
Normally, there's a new instance number for each page analyzed.]
info: Instance #703813535 start. prefs: {"searchpref":" 2","adpref":"2","verbosepref":false}  Include URLs: [".*(www\\.,|)google\\.com\\/search.*",".*news\\.google\\.com\\/.*",".*(www\\.,|)bing.com\\/search.*",".*search.yahoo.com\\/.*",".*(www\\.,|)blekko.com\\/ws\\/.*",".*(www\\.,|)duckduckgo\\.com\\/\\?q\\=.*"]
info: Page to be analyzed: http://www.google.com/search?q=wikipedia+harry+potter&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
...
[Here the content script is working on the URL shown.  This is correct]
info: Instance #703813535  check of document.URL: http://www.google.com/search?q=wikipedia+harry+potter&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
...
[Here, the browser hung for about 5 minutes.  No log messages, no input, window faded. Then it stops hanging. This is semi-repeatable.]
[The Javascript values to prevent hanging are set to: dom.max_chrome_script_run_time;20 dom.max_script_run_time;20]
[So there shouldn't be a hang from the Javascript level.]

[Now we see the SAME instance of the content script working on a DIFFERENT page.  This means the content script is now associated with a different DOM. Uh oh.]
[It really is, too; the content script marks up the wrong page just as it should.]
info: Instance #703813535  check of document.URL: http://en.wikipedia.org/wiki/Harry_Potter
info: Instance #703813535  check of document.URL: http://en.wikipedia.org/wiki/Harry_Potter
info: Instance #703813535  check of document.URL: http://en.wikipedia.org/wiki/Harry_Potter
info: Instance #703813535  check of document.URL: http://en.wikipedia.org/wiki/Harry_Potter
info: Instance #703813535  check of document.URL: http://en.wikipedia.org/wiki/Harry_Potter
info: Instance #703813535  check of document.URL: http://en.wikipedia.org/wiki/Harry_Potter
info: Instance #703813535  check of document.URL: http://en.wikipedia.org/wiki/Harry_Potter
(In reply to John Nagle from comment #5)
Hey I tried using content script with HTTP redirection without noticing any issue. 
John: Can you share some piece of code in order to digg this issue?
If you have used Addon builder, I can start by looking at your online addons.
(Reporter)

Comment 7

6 years ago
Created attachment 574899 [details]
XPI file for development version of add-on which exhibits bug

Try using this test version of an add-on for Google searches, and quickly
click on link results. When you run this, go to the add-on menu for the add-on and check "Turn on debug error messages".  That will generate lots of output in the error console.
I'm testing with current SDK master, which contains major modification with 1.2/1.3 releases.
Here is what I get:
1/ Following exception:
  error: An exception occurred.
  Traceback (most recent call last):
    File "resource://searchrater-at-jetpack-api-utils-data/content-proxy.js",
    line 679, in
    return name in obj || name in overload || name == "__isWrappedProxy" ||
  Error: Permission denied to access property 'document'
This may be a sign of content script mixes between two documents. I'll try to digg this.

2/ All log messages "Check of document.URL:" are about google URLs so that it seems to dispatch workers only on matching documents.

By any chance, do you have a simplier test case?
Don't you have something smaller on addon builder?
(Reporter)

Comment 9

6 years ago
Created attachment 574913 [details]
XPI file for development version of add-on which exhibits bug - rebuilt

Add-on rebuilt with SDK 1.2.1, Firefox 8.  So that's the latest everything.

Able to reproduce problem.  Run under "cfx run", do Google searches, and quickly click on search results until you get a non-search-result page with a rating icon (a circle with a checkmark, question mark, do not enter symbol or a rotating "busy" icon.) That indicates the add-on is running on a page that's doesn't match the page-mod URL patterns.

Then look at the log for entries like this.  The "instance" is a random number generated each time the content script loads.  If you see the same instance number for two URLs, the same content script instance somehow ran on more than one URL.  That's not supposed to happen.

info: Instance #424622615  check of document.URL: http://www.google.com/search?q=house+wrap&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
info: Instance #424622615  check of document.URL: http://www2.dupont.com/Tyvek_Weatherization/en_US/products/residential/resi_homewrap.html
info: Instance #424622615  check of document.URL: http://www2.dupont.com/Tyvek_Weatherization/en_US/products/residential/resi_homewrap.html
info: Instance #424622615  check of document.URL: http://www2.dupont.com/Tyvek_Weatherization/en_US/products/residential/resi_homewrap.html
Attachment #574899 - Attachment is obsolete: true
(Reporter)

Comment 10

6 years ago
Can you reproduce the problem yet?
I think that this bug is mitigated by a recent landing on development branch.
It would be really cool if you can confirm what I'm seeing by cloning our git repository and try your addon with the development version:
  https://github.com/mozilla/addon-sdk

You should have the exception from comment 8.
I was able to track down this exception to "data/searchrating.js", line 522:
  changetimeout = window.setTimeout(
        function() {     startratings(document) },
        kchangetimeoutsecs*1000);

"startrattings" will later call the method that prints these "check of document.URL". That may explain why I'm not seeing same messages than you. 
Now, this script fails when a document mix happens on a content script.
I don't think that we create a worker for non-google pages, instead,
we may be using a valid worker on another document.
Internally it is very easy to share the same worker between two distinct documents of the same tab ...

But the cool thing is that now, in development branch, we have a better security pattern that ends up throwing exception as soon as we start using a worker on another document than the expected one!

Having said that we still have an issue here. setTimeout should have been cancelled so that `startratings` won't be called on another document. I don't know if we are hitting a race condition, as you code is heavy or if we have a bug that prevent setTimeouts to be cancelled on document unload.
(Reporter)

Comment 12

6 years ago
You write:
> I don't think that we create a worker for non-google pages, instead,
> we may be using a valid worker on another document.
Yes. I agree. I've been generating an random "instance number" each time the content script loads, and I'm seeing the same instance number used for two different documents.  So the same old worker is being reused.  A new worker is
not being launched for the same document. 
 
> Internally it is very easy to share the same worker between two distinct
> documents of the same tab ...
Now that you've told me that, I strongly suspect that's where the bug is.

Can you get the new security exception to happen with the development version?

I'm going to try capturing the unload event in my code and cancelling the timer.
(Reporter)

Comment 13

6 years ago
I tried adding

document.addEventListener("unload", pageunload, false); 

in the content script, but "pageunload" is never called.  

Do document-level unload events even work?  See "https://bugzilla.mozilla.org/show_bug.cgi?id=99820"
I've only tested your code with development version.

You should not register `unload` listener as it break BFCache, a cache that optimize back/forward actions in firefox.
setTimeout should be automatically cancelled! 
See bug 666335.

We have to figured out why your setTimeout is still executed in some rare cases
(Reporter)

Comment 15

6 years ago
If I can't capture the "unload" event in the script, then I can't cancel the setTimeout and work around the bug.  So that workaround won't work.

I'm now testing this workaround: 

var docurl = document.URL;     // URL of document being worked on
...
//
//  checkurlchange -- check for change in document URL
//
//  Workaround for Mozilla bug 693345
//
function checkurlchange()
{   if (document.URL != docurl)   // if document URL changed, bug
    {   console.log("ERROR: Mozilla BUG 693345: URL changed from " + docurl + " to " + document.URL);
        return(true);             // trouble
    }
    return(false);                // normal
}

"checkurlchange" is then called in each event listener. If it returns true,
the event is ignored.  And, sure enough, I get messages like

info: ERROR: Mozilla BUG 693345: URL changed from http://www.google.com/search?q=awesome&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a to http://dictionary.reference.com/browse/awesome

The script then stops, which prevents bogus processing on the wrong page. 
This seems to do the right thing for multiple tabs and windows. 

So I now have a workaround for the bug.  This is progress.
(Reporter)

Comment 16

6 years ago
Created attachment 574948 [details]
574913: XPI file for development version of add-on which exhibits bug - with workaround and bug detector

This version of the add-on has a detector and workaround for the bug. It checks that the URL did not change from one use of the content script to the next.  If it detects a URL change, it logs

ERROR: Mozilla BUG 693345: URL changed from http://www.google.com/search?q=awesome&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a to http://dictionary.reference.com/browse/awesome
Attachment #574913 - Attachment is obsolete: true
(Reporter)

Comment 17

6 years ago
This error seems to have induced another error within Jetpack which caused a traceback.  Here, my page mod add-on which fires on Google result pages was running on a Google result page.  I clicked on the Google link for "news",
and got this:

info: ERROR: Mozilla BUG 693345: URL changed from http://www.google.com/search?q=cars&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a to http://news.google.com/nwshp?hl=en&tab=wn
error: An exception occurred.
Traceback (most recent call last):
  File "resource://jid1-eodcuapntbubag-at-jetpack-api-utils-lib/content/worker.js", line 422, in
    emit: function () self._emitEventToContent(arguments)
  File "resource://jid1-eodcuapntbubag-at-jetpack-api-utils-lib/content/worker.js", line 459, in _emitEventToContent
    throw new Error(ERR_DESTROYED);
Error: The page has been destroyed and can no longer be used.

The line " ERROR: Mozilla BUG 693345: URL changed" is a debug check of mine, which reports when the content script sees a different URL than the one it started with.  This indicates that the content script was internally reused, which is the bug.  

In this case, that caused what seems to be an internal error in Jetpack.
This exception is thrown when you are trying to send an event to a worker whose document has been unloaded.
So in your case you may be trying to call:
  worker.port.emit(...)
But this `worker` should not be used anymore, as the document that it targets changed to a new one. A worker only works with one document. As soon as you go to another web page, another Worker is spawn. So that you should not used the old one.
(Reporter)

Comment 19

6 years ago
Re: "But this `worker` should not be used anymore, as the document that it targets changed to a new one. " Right.
The problem, as mentioned previously, is that the SAME content script instance was reused for a new page.  That's the bug. The page-mod API isn't supposed to do that.  This error message is a symptom of that bug.
(Reporter)

Comment 20

6 years ago
Any progress on this?  We have a workaround, but it's rather clunky.
(Reporter)

Comment 21

5 years ago
Still seeing this with SDK 1.6.1, Firefox 12.

File "resource://551f2920-3c19-11e1-b86c-0800200c9a66-at-jetpack/api-utils/data/content-proxy.js", line 698, in 
                return name in obj || name in overload || name == "__isWrappedProxy" ||
            Error: Permission denied to access property 'document'
(Reporter)

Comment 22

5 years ago
Also possibly related:

Timestamp: 5/7/2012 11:56:52 AM
Error: An exception occurred.
Traceback (most recent call last):
  File "resource://551f2920-3c19-11e1-b86c-0800200c9a66-at-jetpack/api-utils/lib/content/worker.js", line 174, in portEmit
    self._addonWorker._onContentScriptEvent.apply(self._addonWorker, arguments);
TypeError: self._addonWorker is null

All of these errors tend to appear when rapidly switching pages in the browser while a content script is still running. 

The bug has been confirmed since November 2011, and should be advanced to "confirmed" state.  This bug has now been open for 7 months.
i can observe a behaviour in my addon built with addon sdk that is possibly related to all your findings.
the content script replaces certain text patterns on webpages. on a loaded page it first determines if it should run on the page based on the parameters emitted by the worker in main.js and if so, it starts with a 
"if (document.body.textContent.search(/XYZ/) != -1)" condition.
however after a user has clicked on a search result on google on each google.com/url?-redirection page there is a "TypeError: document.body is null" coming up in the error console. i assume this is also happening because the content script is still running in a page that has already been replaced by another one.
(Reporter)

Comment 24

5 years ago
See also Bug #648465, which may be related.  

I suspect a race condition somewhere in the add-on system, leading to various bugs as content scripts are reused or applied to the wrong page.

Updated

5 years ago
Target Milestone: 1.3 → ---
(Reporter)

Comment 25

5 years ago
This seems to be occurring more frequently in Firefox 13.  If you have our Ad Limiter add-on installed, when this bug occurs, our checking code detects it and puts a message like this on the error console:

Error: ERROR: Mozilla BUG 693345:
URL changed from 
http://www.google.com/search?q=debris+removal+half+moon+bay&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a#q=debris+removal+half+moon+bay&hl=en&client=firefox-a&hs=ua3&rls=org.mozilla:en-US:official&prmd=imvns&ei=Ez3YT66VLKTg2QXhzpGQDw&start=10&sa=N&bav
=on.2,or.r_gc.r_pw.r_qf.,cf.osb&fp=4e154b18253a8ec1&biw=1540&bih=857

to 

http://www.google.com/search?q=debris+removal+half+moon+bay&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a#hl=en&client=firefox-a&hs=Xb3&rls=org.mozilla:en-US%3Aofficial&sclient=psyab&q=debris+removal+half+moon+bay+california&oq=debris+removal+half+moon+bay+california&aq=f&aqi=&aql=&gs_l=serp.3...34671.36318.0.36651.11.11.0.0.0.0.211.1812.0j10j1.11.0...0.0.cPnU2usr4CE&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&fp=4e154b18253a8ec1&biw=1540&bih=857

This reflects navigating from one page of a Google search result to another one.  The content script is reused for the new page.
(Reporter)

Comment 26

5 years ago
Still broken in Firefox 14.0b7 (beta):

Timestamp: 6/17/2012 8:10:10 PM
Error: ERROR: Mozilla BUG 693345: URL changed from https://www.google.com/search?q=cars&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-beta to https://www.google.com/search?q=cars&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-beta#hl=en&client=firefox-beta&hs=ts8&rls=org.mozilla:en-US%3Aofficial&biw=1318&bih=815&sclient=psy-ab&q=demo+fuel&oq=demo+fuel&aq=f&aqi=g-K4&aql=&gs_l=serp.3..0i30l4.36614.37660.0.37924.9.8.0.0.0.0.381.1942.0j4j1j3.8.0...0.0.qtxZIboo_QI&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&fp=97c5faaa4d036497
Depends on: 766088
Sorry John for being so slow to confirm this issue. I had really hard time to reduce your addon to an actual SDK issue. But thanks to another report today on irc, with a smaller usecase, I was able to spot the issue described in bug 766088. I think that it is highly related to what your are reporting here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I just posted a patch in bug 766088.
Could you give it a try and confirm that it solves your issues?
(Reporter)

Comment 29

5 years ago
OK, that's forward progress.  Thanks. 

When the patch is incorporated into a complete SDK release of some form, let me know, and I'll try it.  I'm not set up to build the SDK.
Actually, you do not need anything else than git to test this patch.
It is even optionnal if you download a zip or tar.gz file of this branch:
.zip:
  https://github.com/ochameau/addon-sdk/zipball/bug/766088-freeze-content-scripts
.tar.gz:
  https://github.com/ochameau/addon-sdk/tarball/bug/766088-freeze-content-scripts

Assuming you are on linux, you could do something like this:
$ wget https://github.com/ochameau/addon-sdk/tarball/bug/766088-freeze-content-scripts
$ tar zxvf ochameau-addon-sdk-0.9-2460-g847d8fa
$ cd ochameau-addon-sdk-g847d8fa
$ source bin/activate
$ cd /path/to/your/addon
$ cfx run

(An SDK release is just a zipped file of our repo)
(Reporter)

Comment 31

5 years ago
OK, I downloaded the test SDK from the above link.  It seems to help.  I haven't been able to trigger the bug, but need to test further.    

The message

"warning: The page is currently hidden and can no longer be used until it is visible again."

appears occasionally, as I click on links with the add-on running.  Does that indicate that the new fix has detected the case where a timeout or message came in after the page became inactive?
Cool, thanks for testing it!

Yes, this message indicate that you are trying to use worker.postMessage or worker.port.emit on an hidden-disabled content script.
It isn't really bad to do so. You might listen to these new events described in bug 766088 comment 2 in order to avoid doing so.
(Reporter)

Comment 33

5 years ago
It's probably better to throw those events out internally than to try to deal with the state changes inside add-ons.  There may be a timing window between "visibility change", "add on is informed of visibility change" and "add on sends message". This imposes a concurrency problem that wasn't there before.  

If this is an issue, I'd suggest raising a Javascript exception when a message is sent to something that can't receive it.  Right now, you can send to a port with no listener, and the sender is never told about it.  That's a design flaw in a message passing system, especially a unidirectional one like this one.  But that's not really relevant to this bug; it's a more general design issue.

(Message passing probably should have been callback-oriented, more like XMLHttpRequest than emit/on.   Then, when there's a delivery problem, you get a callback. Google Chrome does it that way. But I digress.)
(In reply to John Nagle from comment #33)
> It's probably better to throw those events out internally than to try to
> deal with the state changes inside add-ons.  There may be a timing window
> between "visibility change", "add on is informed of visibility change" and
> "add on sends message". This imposes a concurrency problem that wasn't there
> before.  

It isn't really clear what you are suggesting here. I can't do much internally except throwing warning messages or exceptions. In bug 766088, I choosed to send warning messages, but I can switch to exception.
(Reporter)

Comment 35

5 years ago
Is an add-on expected to avoid causing the warning message "warning: The page is currently hidden and can no longer be used until it is visible again"?  If so, and it is expected to listen to "visibility events" to determine if the page is hidden, there may be race conditions.  Visibility events are asynchronous, or at least are not guaranteed by any written specification to be synchronous.

Google Chrome doesn't seem to have this problem.  Take a look at how they do it.
You should end up having similar exception when using: chrome.tabs.connect
  http://developer.chrome.com/extensions/tabs.html#method-connect
Like this bug report:
  http://code.google.com/p/chromium/issues/detail?id=132315

But this is the advanced API and won't face any error when using sendMessage as it will always send the message to whatever document is currently loaded in the given tab.

Having said that, I'm not arguing that our API is perfect, I'm just trying to figure out how to improve bug 766088. I can easily throw exceptions instead of printing warning messages.
(Reporter)

Comment 37

5 years ago
Just come up with some kind of solution that fixes Bug 693345.  That bug makes add-ons fail outright.  

https://bugzilla.mozilla.org/show_bug.cgi?id=693345
Assignee: poirot.alex → nobody
QA Contact: jsantell
This looks like a similar fix that page-worker had #850367 and could be used here as well -- may require refactoring page-mod though
Assignee: nobody → jsantell
QA Contact: jsantell
Blocks: 902217
Whiteboard: [mentor=jsantell@mozilla.com]
Assignee: jsantell → nobody
(Assignee)

Updated

3 years ago
Mentor: jsantell@mozilla.com
Whiteboard: [mentor=jsantell@mozilla.com]

Comment 39

3 years ago
Any updates on this? Quite a serious flaw.
Flags: needinfo?(evold)
(Reporter)

Comment 40

3 years ago
As I recall, this was eventually fixed as a side effect of another change.
(In reply to willmarquardt from comment #39)
> Any updates on this? Quite a serious flaw.

I haven't looked at this. If there is a fix we should have a test though, so I won't close it.
Flags: needinfo?(evold)
This should be fixed, we shouldn't need a test I think because it is the last url which is tested, which is the url of the document which is loaded.

Let's make a new bug if there is still an issue, but the reporter is happy so I think we are good here.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
(Reporter)

Comment 43

3 years ago
The problem of page_mod running the content script on the wrong page seems to have been fixed in 2012. I think we're good here, too.
You need to log in before you can comment on or make changes to this bug.