Closed Bug 1222957 Opened 10 years ago Closed 10 years ago

Radar Loop on ForecastFox Addon not updating

Categories

(Firefox :: Extension Compatibility, defect)

Product:
Firefox
Component:
Extension Compatibility
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox45 --- affected

People

(Reporter: jmjjeffery, Unassigned)

Details

Attachments

(1 file)

JSON Errors in Browser Console
5.78 KB, text/plain
Details
Using the latest m-c win32 builds ForecastFox 2.3.3 the Radar loop stopped updating. Good build: 20151031164352 d3fe65f1b9c10af1f239e6a4e4ffb38580f97fc4 Bad Build: 20151031170152 e958f522a72c1d789f270bc4bea43869294b4a13 No errors that I see in the Browser Console. The URL to fetch the update every 15 mins and update the Radar Loop (a gif image) is: http://sirocco.accuweather.com/nx_mosaic_640x480_public/sir/inmasirIN_.gif Manually opening that URL in a tab updates the Radar Loop, so appearss that Accuweather is not at fault. Here is patches that landed in the 'bad' cset noted above, any patches stand out that may be stopping the update to the Radar Loop ? The forecast parts of the addon are updating as expected, only the Radar is not updating.
I looked request and response headers: http://i057.radikal.ru/1511/33/63e5987ca343.png http://s019.radikal.ru/i604/1511/8d/5ee340cbbfc8.png Accuweather gives the correct headings, without caching images. it's probably some kind of bugs in browser...
I see some networking-related patches in that range. Does this reproduce with e10s disabled by chance?
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #2) > I see some networking-related patches in that range. Does this reproduce > with e10s disabled by chance? Yes, I have had e10s disabled for some time, but still using m-c win32, mainly Tinderbox(hourly) builds.
Enabling e10s makes no difference, Radar Loop is still not updating.
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #5) > For perpetuity (since it's far easier to look at): > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=d3fe65f1b9c10af1f239e6a4e4ffb38580f97fc4&tochange=e958 > f522a72c1d789f270bc4bea43869294b4a13 > > Jim, on a lark, can you try out the two builds below and let me know if > either reproduces? > > e08508d502c8: > https://treeherder.mozilla.org/#/jobs?repo=try&revision=652d055bbb0e > 16ab2ae184c0: > https://treeherder.mozilla.org/#/jobs?repo=try&revision=0a319574ec17 https://hg.mozilla.org/try/rev/652d055bbb0e22ce96b9573fb5cb146883fd4938 Does not update at all, normally on restart of browser the Radar Loop will one (1) time, this does not. Also, with a 'normal' build - I can manually load the Radar-loop in a tab, and the ForecastFox addon will show the new image/gif. This build is not picking up the newer image/gif. https://hg.mozilla.org/try/rev/0a319574ec1733931e5ad2e01b7b3b035b7b5c92 This build picks up the manual update. This build also not updating Radar Loop .gif Thanks Ryan for the 'test' builds.
Forgot to add, build https://hg.mozilla.org/try/rev/0a319574ec1733931e5ad2e01b7b3b035b7b5c92 Will not update on restart of the browser either.
These tests are with e10s OFF: https://hg.mozilla.org/try/rev/652d055bbb0e22ce96b9573fb5cb146883fd4938 Previous tests run with e10s enabled. turned off e10s, and now the Radar .gif will update on restart of browser, as it normally does. Radar Loop .gif still not updating every 15 mins as it should. This build is blocking even 'manual updates' in a tab. https://hg.mozilla.org/try/rev/0a319574ec1733931e5ad2e01b7b3b035b7b5c92 this build not updating the radar gif , or on restart of browser. Manual updates in a tab are working here. Thanks Ryan for the 'test' builds. (In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #8) > Created attachment 8685718 [details] > JSON Errors in Browser Console The above errors are pouring out with the cset: https://hg.mozilla.org/try/rev/0a319574ec1733931e5ad2e01b7b3b035b7b5c92
Things are getting more confusing, sorry... Manual updates work in cset: 20151106151035 e2a910c048dc82fc3be53475f18e7f81f03e377b Manual updates do not work in cset: 20151109055636 e1ef2be156de1dad31bb4189a51b178b12b23340 Manual updates I am testing by entering the URL used for updates in a tab in the browser. http://sirocco.accuweather.com/nx_mosaic_640x480_public/sir/inmasirIN_.gif I don't have all the builds between those csets. The 'new ftp' Directory makes it impossible to find builds by date without opening the .txt file.
(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #10) > Things are getting more confusing, sorry... > > Manual updates work in cset: > 20151106151035 e2a910c048dc82fc3be53475f18e7f81f03e377b > > Manual updates do not work in cset: > 20151109055636 e1ef2be156de1dad31bb4189a51b178b12b23340 > > Manual updates I am testing by entering the URL used for updates in a tab in > the browser. > http://sirocco.accuweather.com/nx_mosaic_640x480_public/sir/inmasirIN_.gif > > I don't have all the builds between those csets. The 'new ftp' Directory > makes it impossible to find builds by date without opening the .txt file. Sorry, for the noise, somewhere I think I made some bad assumtions/testing. Manual updates work with/without e10s enabled in the latest m-c win32 cset, so the above range, issues is wrong.
Retested briefly this morning with latest m-c win32 cset: https://hg.mozilla.org/mozilla-central/rev/cc473fe5dc512c450634506f68cbacfb40a06a23 e10s ON: using the sirocco link in a tab, it will update when I refresh the page. The update is NOT being picked up the ForecastFox addon e10s OFF: Same cset using the sirocco link in a tab, it will update when I refresh the page. The update is being picked up the ForecastFox addon
The last few comments have left me a bit confused as to the current state of things. To confirm my current understanding of things: * The issue only reproduces with e10s enabled. If e10s is off, the ForecastFox addon updates the image as expected. * Both Try builds reproduced the issue (neither properly updated). Is that all correct? Also, how did you narrow down the regression range from comment 0 to begin with?
Flags: needinfo?(jmjeffery)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #13) > The last few comments have left me a bit confused as to the current state of > things. To confirm my current understanding of things: > > * The issue only reproduces with e10s enabled. If e10s is off, the > ForecastFox addon updates the image as expected. > * Both Try builds reproduced the issue (neither properly updated). > > Is that all correct? Also, how did you narrow down the regression range from > comment 0 to begin with? There seems to be to two (2) problems, hopefully only one (1) fix. Both 'try builds' did not work in that the image was never updated. Even thought the image is NOT updating, if I manually visit the update link in another tab, the ForecastFox is picking up the image, with e10s off. With E10s ON, its not picking up/updating the image even though it was manually updated in an external tab. I narrowed down the range by testing hourly (tinderbox) builds. (m-c win32 builds) I've been last two days trying to test m-i builds, but finding the right builds on m-i tinderbox with the csets listed the regression range is a slow, tedious process. Already have two (2) days invested and not getting anywhere fast, plan on doing more testing this week-end. Sadly I have to do it manually, as I have no idea how to setup and use moz-regression and installing Purl or whatever it is is above my level of understanding.
Flags: needinfo?(jmjeffery)
All testing has been done in an non-e10s setting on win7 x64. Okay, after 3 intensive days of testing I'm ready to throw in the towel. Using the list of landed csets: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d3fe65f1b9c10af1f239e6a4e4ffb38580f97fc4&tochange=e958f522a72c1d789f270bc4bea43869294b4a13 Only one that reliably works is the bottom one: 20151030102633 0095ee7c07a34c940a30836704b5dff9107be686 Testing builds upward from the bottom 6 others work until I get to build: 20151030130506 e08508d502c88b8f95baa1b8e72f159d6d27934d bug 1202085 (six part patch) All other builds in the the above noted cset fail and are not updating the radar gif. The first 6 builds from the bottom up work. I don't know how to proceed. Perhaps other builds from Fx-team are involved ? I don't know how the csets presented in the list actually landed into m-i, by that I mean what sequence, are the cset's chronilogical ? If so, from top down, up bottom up ? I suspect the patch from bug 1202085 is the culprit. When dev's write patches I assume they all pull from 'tip' thus if bug 1202085 is the bad cset that would mean that all other patches in the main cset that fail also have the buggy cset ? Ryan, if you read this would it be too much to ask to spin a try-build without bug 1202085 ?
Bug 1202085 doesn't back out cleanly, but it certainly seems like a plausible candidate indeed. Seth, since Ehsan is on PTO, can you please take a look?
Flags: needinfo?(seth)
Ehsan, can you please take a look at this?
Flags: needinfo?(seth) → needinfo?(ehsan)
What specifically do you want me to do with this bug? It seems like the add-on author needs to update their code if it's broken because of https://hg.mozilla.org/mozilla-central/rev/9c5e6d68cc46. (I can't tell for sure whether that is the case because of bug 1233879.) At any rate, the fix for bug 1202085 will remain as is.
Flags: needinfo?(ehsan)
Component: Networking → Extension Compatibility
Product: Core → Firefox
Given that you're the first person in the bug to point out that the interface changed and the addon needs updating, that's exactly what was needed.
Fixed version of ForecastFox now on AMO: https://addons.mozilla.org/en-US/firefox/addon/forecastfox-fix-version/?src=ss Radar now updates... Looks like my original anaylsys was somewhat correct in relation to the bug that removed the imgcache, see this post and following reference the addon: http://forums.mozillazine.org/viewtopic.php?p=14479271#p14479271
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: