#22: one-artist-per-page (Fixed)
| Reported by: | Assigned to: | jamie | |
|---|---|---|---|
| Priority: | Major | Milestone: | 1.0 "talks to add-art.org" |
| Release: | Component: | add-art Firefox extension |
Maintain enough state (possibly using the about:config preferences?) to make sure each page loads art from the same artist.
Changelog:
Modified by – Jan 18 2008 * 13:50
- Component set to add-art Firefox extension
Modified by – Mar 12 2008 * 18:12
- Milestone changed from 1.0 "talks to add-art.org" to 0.5 "hard-coded into chrome"
from my comments on Ticket [#32],
We are currently hooking into the function shouldLoad from abp and overloading that in our code. I think there may be some once per page code in abp that we can do a similar hook from and get our single random number per page. with that stored in the abp class, we should be able to ref it from our modified shouldload code and then bob’s yer uncle.
Modified by – Mar 12 2008 * 18:24
just a note, the shouldLoad function we are overriding seems to be located in ad block plus’s policy.js file.
chrome/adblockplus.jar/content/policy.jsModified by – Mar 12 2008 * 19:46
- Milestone changed from 0.5 "hard-coded into chrome" to 1.0 "talks to add-art.org"
Modified by – Mar 12 2008 * 19:48
whoops, pushed to 1.0 again.
Modified by – Mar 19 2008 * 22:06
Added a small hack in r51 [r51] to use the page URL to generate a pseudo-random # for one-artist-per-page.
Arguably produces “web as Chelsea” effect, whereby specific pages always have the same art for the duration of their show. Like the real world, yknow? In which case r51 would close this ticket :)
Modified by – Mar 20 2008 * 21:49
@Jamie – aaaaaactually, I am running r57 with the color fields. When I went to http://nytimes.com I got green banners, then I went to http://www.nysun.com/ and got green and orange banners. It’s not 1/page yet. Thinking maybe both papers use the same ad service?
Modified by – Mar 22 2008 * 15:39
- Assigned user set to jamie
Modified by – Mar 22 2008 * 18:14
nysun.com dual-banners is caused by iframes, which are actually a different document. Looking into some hacks to see if the current element is an iframe and target its parent window for the seed instead
Modified by – Mar 22 2008 * 19:45
- Status changed from Open to Fixed
[r63] has a patch which will attempt to break out of an iframe to calculate the 1/page seed
iframes located on a different domain name than the main page (e.g. oasis.nysun.com iframe on nysun.com) are unable to access the parent page’s information—this is the definition of a cross-site scripting attack. Tragically this is the vast majority of iframe ads. :\
Closing this ticket as this is impossible to avoid with existing method. Could possibly handle using some kind of state maintenance in about:config parameters, for which we should file a different ticket (and which is probably not “tab-safe”, like thread race conditions)
RSS feeds