All users were logged out of Bugzilla on October 13th, 2018

Two "Untitled Stack"s in this morning's browsing data

RESOLVED FIXED

Status

RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: deb, Assigned: gbrander)

Tracking

Details

Attachments

(1 attachment)

I started testing on Stage this morning, having never used stage before, and I already have two "Untitled Stack"s in my drawer.  They appear to be empty as far as I can tell.  Olivier says he has the same issue.
Created attachment 616177 [details]
Clicking on one of the Untitled Stacks popped up this error

Not sure if this is helpful, but trying to open one of the Untitled Stacks generated this error dialog (screenshot attached).
Just noticed a couple more Untitled Stacks have shown up (around 1:30pm eastern time, Wednesday).  Not sure what's causing them, but they show up at the bottom of the stacks list (except for one "people" stack, which I don't understand at all).
Component: Back-end → Front-end
QA Contact: backend → frontend
This seems to happen when you create a new social stack
restarting the app gets rid of the untitled stack, until the buggy code path gets triggered again
(Assignee)

Comment 5

7 years ago
Hmm. I haven't been able to reproduce this in the dev app -- I'm sure it exists, but not sure what triggers it.
Steps to reproduce:

1) have some posts in the social feeds
2) tap on one of the posts in the social feed, web view shows up
3) bring the drawer into view
4) hit <stacks
5) scroll to the bottom until you find an 'Untitled Stack'
(Assignee)

Updated

7 years ago
Assignee: nobody → gbrander
(Assignee)

Comment 7

7 years ago
The untitled stack gets appended IN ADDITION to the original stack. 1 untitled stack is appended per social result clicked.
(Assignee)

Comment 8

7 years ago
This code in `onNewPlace` is very suspicious:

	      var collection = this.stacksCollection,
          stacks = collection.parse({
            thumbnails_job: msg.thumbnails_job,
            d: [stackData]
          }),
          idx = collection.length-1; // could get an index from the message?

      collection.add(stacks, { at: idx }, { silent: true });

Theory: when the stack is navigated to, it is loaded from the server side (since it has already been created in `top`). This is why it appears in the correct location. The broken stack, however, is appended to the bottom of the list.

The text "Untitled Stack" comes from stacklistview.js. It is shown when no `stack_title` is available on the model.
(Assignee)

Comment 9

7 years ago
I doubt onNewPlace is the culprit.
(Assignee)

Comment 10

7 years ago
Code is from onNewStack
(Assignee)

Comment 11

7 years ago
A temporary fix: https://bitbucket.org/mozillapancake/pancake/changeset/0b4826002d32. 

Working on a complete fix that does not require a second request to the server. Will include regression test.
(Assignee)

Comment 12

7 years ago
Fixed in https://bitbucket.org/mozillapancake/pancake/changeset/ab16570686d4.

Added code and tests for:

* Bridge.prototype.createSocialStack -- a messaging facade that requests a social stack be created
* Top social:create handler that relays messages from main to drawer
* Click handler for main that calls createSocialStack
* Message handler for drawer that creates the stack, adds it to the drawer, POSTS the stack and populates the additional details.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Assignee)

Comment 13

7 years ago
Ready for merge with default as of this commit https://bitbucket.org/mozillapancake/pancake/changeset/f8b85f039cea.

An unrelated bug with stacks causes them not to be highlighted the second time you click into them. The issue is also in default, so not a problem with this branch. https://bugzilla.mozilla.org/show_bug.cgi?id=750339
(Assignee)

Comment 14

7 years ago
I found a bug in the branch's current state: when adding new places to the same user, the stack is added at the wrong place.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 15

7 years ago
*sorry, that is, the place is added at the wrong location. This may not be a bug in this branch at all.
(Assignee)

Comment 16

7 years ago
In default, places aren't even added to the stack if the user is the same.
(Assignee)

Comment 17

7 years ago
The collection is actually getting pieced together in the wrong order somehow.

Theory: I believe the controller for `/id/place_id` gets called before the place exists in the collection. A fetch ensues. The result is diff'd and old models are not modified in any way. The new model then ends up at the bottom, simply because that is where it happens to be `add`ed.
(Assignee)

Comment 18

7 years ago
Creating a separate bug for this.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
(Assignee)

Updated

7 years ago
Blocks: 748182
(Assignee)

Comment 19

7 years ago
Added bug for places collection sorting: https://bugzilla.mozilla.org/show_bug.cgi?id=750546. The places collection sorting is incorrect, but in the current default branch, you can't even add places to existing person stacks!
(Assignee)

Updated

7 years ago
Blocks: 747149
You need to log in before you can comment on or make changes to this bug.