629122 - Crashed tab causes displayport to stop setting

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Panning/Zooming, defect)

Description

[Benjamin Stover (:stechz)]

This is because browser.active is no longer true.

Comment 1

[Benjamin Stover (:stechz)]

Attachment: Crashed tab causes displayport to stop setting

Comment 2

[Benjamin Stover (:stechz)]

Comment on attachment 507196 [details] [diff] [review]
Crashed tab causes displayport to stop setting

Added mfinkle for feedback. I think it's bad that we have selecting a tab code in more than one place, because then we can update one without updating the other (exactly what happened here). If you agree, we can file a bug.

Comment 3

[Wesley Johnston (:wesj)]

Comment on attachment 507196 [details] [diff] [review]
Crashed tab causes displayport to stop setting

I think you are right about selectedTab. Why not call

Browser.selectedTab = Browser.selectedTab

Then we can adjust the setter, and kill off the rest of the stuff in that restore section?

Comment 4

[Benjamin Stover (:stechz)]

Because of:
http://mxr.mozilla.org/mobile-browser/source/chrome/content/browser.js#756

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 507196 [details] [diff] [review]
Crashed tab causes displayport to stop setting

Can we just make this part of the resurrection process?

http://mxr.mozilla.org/mobile-browser/source/chrome/content/browser.js#2611

let active = this.active;

// kill and re-create
http://mxr.mozilla.org/mobile-browser/source/chrome/content/browser.js#2615

if (active)
  this.active = true;

(only fire the active property if this tab was really active. no sense firing the de-activation code)

Comment 6

[Benjamin Stover (:stechz)]

Attachment: Crashed tab causes displayport to stop setting

Comment 7

[Benjamin Stover (:stechz)]

Landed http://hg.mozilla.org/mobile-browser/rev/994fa1d84081

Comment 8

[Andreea Pod]

Can somebody verify this bug?