tab._tabViewTabIsRemovedAfterRestore should be attached to the tabItem rather than the xulTab

RESOLVED FIXED in Firefox 7

Status

Firefox Graveyard
Panorama
RESOLVED FIXED
6 years ago
a year ago

People

(Reporter: dao, Assigned: ttaubert)

Tracking

Trunk
Firefox 7
Dependency tree / graph

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

6 years ago
Since bug 664549 landed, I see this message a couple of times in a mochitest-browser-chrome log, e.g.:

TEST-INFO | chrome://mochitests/content/browser/browser/base/content/test/tabview/browser_tabview_bug591706.js | Console message: TypeError: item.tab is null = {fileName: 'chrome://browser/content/tabview.js', lineNumber: 3298, }

That line appears to be in GroupItem_remove:

      // if a blank tab is selected while restoring a tab the blank tab gets
      // removed. we need to keep the group alive for the restored tab.
      if (item.tab._tabViewTabIsRemovedAfterRestore)
        options.dontClose = true;

Two thoughts:
- Apparently GroupItem_remove is called after TabItems_unlink -- is this expected?
- _tabViewTabIsRemovedAfterRestore really shouldn't be set on the tab, it should be a flag on the item.
Created attachment 540035 [details] [diff] [review]
patch v1

(In reply to comment #0)
> - Apparently GroupItem_remove is called after TabItems_unlink -- is this
> expected?

It's expected because in GroupItem.destroy() we first try to close a tab and only if that succeeded we're removing it from the group.

> - _tabViewTabIsRemovedAfterRestore really shouldn't be set on the tab, it
> should be a flag on the item.

That is the easiest solution and what the patch does.
Assignee: nobody → tim.taubert
Status: NEW → ASSIGNED
Attachment #540035 - Flags: review?(dao)
(Reporter)

Updated

6 years ago
Attachment #540035 - Flags: review?(dao) → review+
This is fixed by bug 663421 because the failing LOC is removed. The only place where we access tab._tabViewTabIsRemovedAfterRestore is now in onTabClose(tab) where an xulTab is passed. So I think we should not change the current behavior and let it remain a flag on the xulTab.
Blocks: 660175
Depends on: 663421
(Reporter)

Comment 3

6 years ago
It doesn't belong on the tab, never did... This is all tabview code.
No longer blocks: 660175
No longer depends on: 663421
Created attachment 540041 [details] [diff] [review]
patch v2

(In reply to comment #3)
> It doesn't belong on the tab, never did... This is all tabview code.

Yeah, you're right. Removed the groupitems.js changes based on bug 663421. Did you remove the bug dependencies intentionally?
Attachment #540035 - Attachment is obsolete: true
Attachment #540041 - Flags: review?(dao)
(Reporter)

Comment 5

6 years ago
Comment on attachment 540041 [details] [diff] [review]
patch v2

(dependencies got cleared due to my comment colliding with your change to the bug)
Attachment #540041 - Flags: review?(dao) → review+
Blocks: 660175
Depends on: 663421
Summary: TypeError: item.tab is null = {fileName: 'chrome://browser/content/tabview.js', lineNumber: 3298, } → tab._tabViewTabIsRemovedAfterRestore should be attached to the tabItem rather than the xulTab
(Reporter)

Updated

6 years ago
No longer blocks: 664549
http://hg.mozilla.org/integration/mozilla-inbound/rev/b3b509e9fbde
Whiteboard: [inbound]
Pushed:
http://hg.mozilla.org/mozilla-central/rev/b3b509e9fbde
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 7
Whiteboard: [inbound]
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.