Closed Bug 629004 Opened 13 years ago Closed 13 years ago

crash dimissing test pilot notification [@ nsViewManager::SetViewVisibility ]

Categories

(Core :: Web Painting, defect)

Product:
Core
Component:
Web Painting
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla2.0b11

People

(Reporter: jaas, Assigned: jono)

References

Details

(Keywords: crash, regression, topcrash, Whiteboard: [fixed by backout of bug 562138])

Crash Data

The top crash on Mac OS X for beta 10 so far is a crash at "nsViewManager::SetViewVisibility". Almost all of the comments make mention of the test pilot notification.
blocking2.0: --- → ?
Severity: normal → critical
Keywords: crash, topcrash
tracy, jono, do we know how to reproduce this?
Odd that we did not see this during testing as this is an action that I performed. Was a new study rolled out recently?
My bad, it was supposed to be on my list to check with the test pilot team since we ran into a problem before. They have a wiki page of upcoming studies...I don't see anything https://intranet.mozilla.org/Labs/TestPilot/Upcoming.
I was so heads down in Sync testing last week, I didn't get a chance to test beta10 and TP.  

This is easily reproducible:

STR:

1) Open chrome://testpilot/content/debug.html
2) Choose A Week in the life of a Browser (v2)
3) Click Reset Task
4) Click Notify me
5) In resulting notification, click the [x] to dismiss it.

Crash.

Can also be reproduced with Firefox 4 Beta Interface (part 2) study.
clicking "more info" in the notification also triggers the crash.
Summary: crash showing test pilot notification [@ nsViewManager::SetViewVisibility ] → crash dimissing test pilot notification [@ nsViewManager::SetViewVisibility ]
Hi everybody.
Thanks for bringing this up. I will look into it.

We didn't release a new study, but there were some changes to Test Pilot that I believe got into beta 10.  One of them might be responsible.

I just tried Tracy's steps on beta 9 on Mac OS -- no crash.  Will download beta 10 and try again to reproduce.
Assignee: nobody → jdicarlo
Status: NEW → ASSIGNED
I can't reproduce with beta10 on Win7
Also reproducible (on Mac) when clicking Submit button at study finish notification.
Severity: critical → blocker
Just tried on beta 10 on Mac OS 10.6.5 resting "Week in the Life of a Browser (v2)" and clicking both the [x] and the "More info" link.  Both of them behaved as expected and didn't trigger the crash.

This was using the Test Pilot hg trunk though, which is not exactly the same as the version bundled with beta 10.  Let me try with that version.
OK, tried it on b10, fresh profile, bundled version of Feedback 1.0.4.  Tried both "week in the life of a browser v2" and "firefox 4 beta interface v2" study.  Tried both [x] and "more info".  Could not trigger the crash at all.

I wonder what might be different?  I'm stumped.

Tracy, if you have a profile where you can consistently reproduce the crash, could you turn that profile into a zip file and send it to me (or attach to this bug)?  That might at least help us narrow it down to whether it's a difference in profiles or a difference in some OS thing external to Firefox.
Can we disable the study for now, as a proactive / protective measure?
I don't think this is study specific.
The way Tracy describes it, it sounds like it can be triggered by multiple studies.  Maybe even "any study".  So we might need to disable everything.

What I could do is add code to all the active studies that tells them not to run if Firefox version is b10 and OS is Mac.

Tracy, Tony, Marcia, Sheila - could one of you who is able to reproduce the crash possibly help us narrow down which studies cause it? Is there any study that *doesn't* cause it?

Thanks a lot.
crash report comments on the signature vary on test pilot actions

4 -- closing the 'Test Pilot' box

5 -- Click "Pilot Study" notification or Crash upon closing a Mozilla notification balloon (via x)

2 -- I clicked submit this time on the pilot

2 -- i clicked on "learn more."

1 -- I clicked show details on some test pilot something that popped up on my screen.
Looking at the crash-stats that Carsten linked to, I see that every single one is on an amd64 processor and almost every one is on Mac OS 10.6.6.  Meanwhile, I'm on 2.66 Ghz Intel core and Mac OS 10.6.5 and I cannot reproduce the crash even using a profile that Tracy sent me on which he had previously reproduced it.

Given that, I suspect the behavior of the crash is dependent either on the processor or on the OS version; maybe both.
Another stack which I found when looking at Mac crash stats which shows the same type of comments as this bug is: [@ nsFrame::FireDOMEvent]. This report is an example of one of the comments: http://crash-stats.mozilla.com/report/index/94ec31b6-fb1f-47bc-9afb-4f7f82110126
Luckily we just gained the ability to turn studies on/off based on arbitrary variables.  I am now working on using this ability to implement something that will turn off all studies on Mac OS 10.6.6 on beta 10.  (We can tweak those factors as we learn more about exactly what causes the crash and where it occurs.)
This crash happens on more than just 10.6.6, it also happens on 10.6.5 and 10.6.4. This may be specific to Mac OS X 10.6, but probably not to a specific version of Mac OS X 10.6.
OK, done in http://hg.mozilla.org/labs/testpilotweb/rev/601125ac929f  -- both studies will now deactivate is OS is Mac 10.6.* (any 10.6) AND firefox is b10.  The change has already been pushed to the test pilot server.  We can see if this reduces the number of crash reports.  We can change it back to active deployment once we solve the underlying bug.

I'm wondering if the notification for the survey ("Pilot Background Survey") can also trigger the crash, or only the notifications for the two studies?
It seems like any notification - study, survey, beginning, ending -- can trigger the crash.  Always when the notification is dismissed or disappears.

And the crash is at nsViewManager::SetViewVisibility.

So it sure seems like dismissing the notification calls something which calls SetViewVisibility, maybe with some bad arguments, and then the crash happens.

The common point in the Test Pilot code for all methods of dismissing/closing the notification is TestPilotSetup._hideNotification(), which looks like this:

  _hideNotification: function TPS__hideNotification(window, onCloseCallback) {
    let popup = window.document.getElementById("pilot-notification-popup");
    popup.hidden = true;
    popup.setAttribute("open", "false");
    popup.removeAttribute("tpisextensionupdate");
    popup.hidePopup();
    if (onCloseCallback) {
      onCloseCallback();
    }
  }

Maybe we can use this to make a minimal test case for reproducing the bug.
This might have been caused by bug 562138 which landed between beta 9 and beta 10 and changed code regarding nsView visibility. That bug has been backed out now for causing two other bugs.

(In reply to comment #22)
>   _hideNotification: function TPS__hideNotification(window, onCloseCallback) {
>     let popup = window.document.getElementById("pilot-notification-popup");
>     popup.hidden = true;
>     popup.setAttribute("open", "false");
>     popup.removeAttribute("tpisextensionupdate");
>     popup.hidePopup();
>     if (onCloseCallback) {
>       onCloseCallback();
>     }
>   }

Is this code baked into Beta 10 or can it be updated separately?
Backing out bug 562138 fixed this crash as well.

Tested by building the latest testpilot1.1pre1.xpi, confirmed the crash on nightly build of 2011-01-25. Then upgraded to nightly build of 2011-01-27, no crash.
Depends on: 562138
Markus: It's baked in (as part of the Feedback add-on that is bundled with the beta).  Why, is there something wrong with it?

If backing out 562138 fixed this crash, then does that mean I can re-enable the studies for Mac OS?  Or should I wait until beta 11 to re-enable them?
(In reply to comment #25)
> Markus: It's baked in (as part of the Feedback add-on that is bundled with the
> beta).  Why, is there something wrong with it?

No, but we could have looked for workarounds that don't trigger the crash. OK, so there's no need to do that.

> If backing out 562138 fixed this crash, then does that mean I can re-enable the
> studies for Mac OS?  Or should I wait until beta 11 to re-enable them?

I think you should wait until beta 11... I don't understand how the fact that the backout fixed the crash influences our decision about re-enabling it in beta 10. We can't back it out of beta 10.
(In reply to comment #26)

Ah, OK, thanks for the clarification.  The studies will be re-enabled for beta 11.  Until then it doesn't seem like there's anything more to be done here.
How can we triage this bug. Is it resolved? Can we remove the blocking 2.0=? flag?. We would then reopen if we saw this in Beta11 for some reason.
Resolving.
Blocks: 562138
Status: ASSIGNED → RESOLVED
blocking2.0: ? → ---
Closed: 13 years ago
No longer depends on: 562138
Keywords: regression
Resolution: --- → FIXED
Whiteboard: [fixed by backout of bug 562138]
Target Milestone: --- → mozilla2.0b11
Crash Signature: [@ nsViewManager::SetViewVisibility ]
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.