978559 - TypeError: this.view.dbView is null when doing archive

Status: RESOLVED WORKSFORME

(Thunderbird :: Folder and Message Lists, defect)

Description

[opera wang]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140212131424

Steps to reproduce:

1. select a lot of messages
2. Press 'A' to archive selected message
3. quickly select 'account name' to make sure no folder is selected, so there's no email is shown




Actual results:

ERROR: TypeError: this.view.dbView is null; Source: 'chrome://messenger/content/folderDisplay.js'; Line: 1359


Expected results:

no error message

Comment 1

[opera wang]

The issue happens because hintMassMoveStarting/hintMassMoveStarting expect folder is selected, but archive is doing the job by many batches.

The situation will be worse if archive is triggered by extension like autoarchive.

Suggest to test this.view.dbview whenever using it, there's some places in folderDisplay.js test it like:
    if (this.view.dbView)
      return this.view.dbView.selection;
    else
      return null;
but not all.

Comment 2

[brummolix]

Just voted, because user of AutoArchiveReloaded Extension report a similar bug.
See https://github.com/Brummolix/AutoarchiveReloaded/issues/1

Comment 3

[ISHIKAWA, Chiaki]

I see the following error 11 times during |make mozmill| test suite run locally:
 JavaScript error: chrome://messenger/content/folderDisplay.js, line 2514: TypeError: this.view.dbView is null


     11 JavaScript error: chrome://messenger/content/folderDisplay.js, line 2514: TypeError: this.view.dbView is null

Looking at the code below, we may simply return from the function when this.view.dbView is null (given the comment near the beginning of the function.).

 2483	  /**
 2484	   * Ensure the given view index is visible, optionally with some padding.
 2485	   * By padding, we mean that the index will not be the first or last message
 2486	   *  displayed, but rather have messages on either side.
 2487	   * We have the concept of a 'lip' when we are at the end of the message
 2488	   *  display.  If we are near the end of the display, we want to show an
 2489	   *  empty row (at the bottom) so the user knows they are at the end.  Also,
 2490	   *  if a message shows up that is new and things are sorted ascending, this
 2491	   *  turns out to be useful.
 2492	   */
 2493	  ensureRowIsVisible: function FolderDisplayWidget_ensureRowIsVisible(
 2494	      aViewIndex, aBounced) {
 2495	    // Dealing with the tree view layout is a nightmare, let's just always make
 2496	    //  sure we re-schedule ourselves.  The most particular rationale here is
 2497	    //  that the message pane may be toggling its state and it's much simpler
 2498	    //  and reliable if we ensure that all of FolderDisplayWidget's state
 2499	    //  change logic gets to run to completion before we run ourselves.
 2500	    if (!aBounced) {
 2501	      let dis = this;
 2502	      window.setTimeout(function() {
 2503	          dis.ensureRowIsVisible(aViewIndex, true);
 2504	        }, 0);
 2505	    }
 2506	
 2507	    let treeBox = this.treeBox;
 2508	    if (!treeBox)
 2509	      return;
 2510	
 2511	    // try and trigger a reflow...
 2512	    treeBox.height;
 2513	
 2514	    let maxIndex = this.view.dbView.rowCount - 1;   // <=== ****
 2515	
 2516	    let first = treeBox.getFirstVisibleRow();
 2517	    // Assume the bottom row is half-visible and should generally be ignored.
 2518	    // (We could actually do the legwork to see if there is a partial one...)
 2519	    const halfVisible = 1;
 2520	    let last  = treeBox.getLastVisibleRow() - halfVisible;
 2521	    let span = treeBox.getPageLength() - halfVisible;
 2522	    let [topPadding, bottomPadding] = this.visibleRowPadding;
 2523	
 2524	    let target;
 2525	    // If the index is after the last visible guy (with padding), move down
 2526	    //  so that the target index is padded in 1 from the bottom.
 2527	    if (aViewIndex >= (last - bottomPadding))
 2528	      target = Math.min(maxIndex, (aViewIndex + bottomPadding)) - span;
 2529	    // If the index is before the first visible guy (with padding), move up
 2530	    else if (aViewIndex <= (first + topPadding))  // move up
 2531	      target = Math.max(0, (aViewIndex - topPadding));
 2532	    else // it is already visible
 2533	      return;
 2534	
 2535	    // this sets the first visible row
 2536	    treeBox.scrollToRow(target);
 2537	  },

Comment 4

[ISHIKAWA, Chiaki]

I filed bug 1338798 for the particular bug in comment 3.

Comment 5

[ISHIKAWA, Chiaki]

Attachment: this.view.dbView is null. Recorded nine times (?)

While I was checking other errors by looking into error console (so called browser console now),
I noticed that I see this error, this.view.dbView is null. in the current 60.7.2 (64-bit) which I use under linux for daily office work.
This is a bit disconcerting...

Since I don't really realize much ill-effect for this error thrown by the interpreter,
I think we can return immediately if this.view.dbView is null where the error is thrown.

updateStatusResultText: function() {
let rowCount = this.view.dbView.rowCount; <--- check the nullness and return immediately.
let statusMsg;

if (rowCount == 0) {
  statusMsg = gSearchBundle.getString("noMatchesFound");
}

Comment 6

[Wayne Mery (:wsmwk)]

Chiaki, does this still reproduce for you?

Comment 7

[ISHIKAWA, Chiaki]

(In reply to Wayne Mery (:wsmwk) from comment #6)

Chiaki, does this still reproduce for you?

No. I think it has been solved in
bug 1338798, and
bug 1318776.

So I am setting this entry as FIXED.

Except, I opened the error console to verify it, and saw a flurry of other errors int the error console with TB 91.10.0 under Windows 10 :-(
I will file the issues in bugzilla.

Comment 8

[Magnus Melin [:mkmelin]]

-> WFM (no known patch fixed the issue)