Door hanger out of sync w/ dropdown

[pdehaan]

In in the "private" branch, and after browsing for a while, Firefox blocked 1148 trackers and 50 advertisements., I noticed my address bar is out of sync with the dropdown.

I didn't see anything in the Browser Console...

[pdehaan]

Refreshing the page, http://www.etonline.com/, seems to solve it – so it seems like it's an intermittent issue:

[pdehaan]

Using the latest code in master branch, which seems to be:

$ git rev-parse --short HEAD # fb592fb

[pdehaan]

Also saw the same thing on Twitter...

[pdehaan]

OK, marginally more interesting... It's almost like the first time I load the page, the door hanger isn't updating. Like, if I go to https://stackoverflow.com/questions/5694389/get-the-short-git-version-hash the address bar will say it blocked 6 somethings. If I open the door hanger, it will say "0 trackers blocked" and "0 ads blocked". Now, If I switch to any other open tab, the address bar and doorhanger don't seem to update, and still say that same 6/0/0. Next, if I switch to my "about:preferences" tab, the icon in the address bar disappears, so I cannot view the door hanger. Switching back to my previously open "www.etonline.com", "www.twitter.com", or "stackoverflow.com" tabs, the address bar icon isn't visible unless I refresh again.

[pdehaan]

One last observation... Things seem to work OK for me locally when the door hanger is open, but after it closes and reopens, it seems like everything resets to zero.

It's a pretty poor GIF, but in the first half you can see the address bar says 19 blocked trackers. But when you open the door hanger, it says zero. The second half is during a refresh, and the door hanger is accurate if it's open during the page load. But after closing and reopening, everything resets back to zero.

[biancadanforth]

I have merged some changes into master since you filed this, but I am currently testing on the same commit you reference in this issue.

I am guessing at least part of this intermittent bug is related to #130 (if you CTRL/CMD + click a link or right click a link and 'Open in a New Tab', the pageAction badge resets). I just fixed and merged this after you created this issue.

That doesn't cover everything you're seeing, unfortunately.

I can't reproduce:

• pageAction button not reappearing on tab change from about:preferences to an http(s) page.
• pageAction numbers are both 0 even when pageAction badge reads non-zero and this error persists between tab changes.
  • Unreplicated pre-condition: pageAction badge is non-zero and the numbers are 0.

I'll keep trying to see if I can find some examples. I don't doubt it's happening, just having trouble getting it to happen for me.

@pdehaan , Could you try fetching the latest changes from master and seeing if you can get some more details about your order of operations if you do find similar behavior again?

[pdehaan]

OK. using $ git rev-parse --short HEAD # fb592fb, I'm unable to repro this either.

{"version":3,"study_name":"trackingProtectionMessagingExperiment","branch":"private","addon_version":"1.0.1","shield_version":"4.1.0","type":"shield-study-addon","data":{"attributes":{"message_type":"event","event":"panel-hidden","panel_type":"page-action-panel","showTime":"193"}},"testing":false}

[pdehaan]

Unbranded FF Beta 58.0.2, I'm seeing the behavior again w/ $ git rev-parse --short HEAD # 49185d7:

{
  "version":3,
  "study_name":"trackingProtectionMessagingExperiment",
  "branch":"fast",
  "addon_version":"1.0.1",
  "shield_version":"4.1.0",
  "type":"shield-study-addon",
  "data":{
    "attributes":{
      "message_type":"event",
      "event":"new-tab-closed",
      "newTabOpenTime":"216"
    }
  },
  "testing":false
}

[pdehaan]

Continuing this absurd thread... I am unable to reproduce this in Unbranded FF Beta 59.0b14 (64-bit macOS) w/ $ git rev-parse --short HEAD # dbf114d. *sigh*

{
  "studyName":"trackingProtectionMessagingExperiment",
  "addon":{
    "id":"tracking-protection-messaging-study@shield.mozilla.org",
    "version":"1.0.1"
  },
  "variation":{
    "name":"fast",
    "weight":1
  },
  "shieldId":""
}

[biancadanforth]

I am seeing a reproducible bug that may be related on "fast" branch.

Effect: After visiting a number of sites in a non-private window, as soon as I open a private window and then switch back to the original, non-private window, the pageAction badges all read the same value (1s in my case) and the pageAction panels all read "0" and "0" for trackers and seconds.

Steps to reproduce:

1. In Unbranded Beta, force the "fast" or "private" treatment branch
2. Visit "npr.org" in the first tab.
3. Dismiss the intro panel.
4. Open a second new tab and visit "nytimes.com".
5. Open a third new tab and visit "facebook.com"
6. Notice the values between the 3 tabs are different. Ex: the first tab with "npr.org" reads ~2s/46/2, the second tab with "nytimes.com" reads ~1s/27/1 and the third tab "facebook.com" reads ~0s/0/0.
7. Leaving this non-private window open, open a new private window.
8. Without going to any pages in the new window, click back to the non-private window and check the pageAction badge and pageAction panel values for each of the three tabs. The first tab with "npr.org" reads ~1s/0/0, as do the other two tabs.

The expectation is that they should have the same values as before or slightly increased if the page is still making requests. They certainly should not reset or decrease.