865279 - Adding bookmark to full homescreen does not create a new panel

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

Description

[Zac C (:zac)]

Gecko revision=7d1df39eff1d6f96c1ebe8bdab997c0c3df769ac
Gaia revision=140a9f7a6ade455763aca5e65b2572a51c731746
BuildID = 20130423230207
Version = 18.0

Adding a Browser bookmark (and perhaps others too) when the homescreen panels are full does not add a new panel. The bookmark is not saved and no notification is given to the user.

STR
1. Fill up yer homescreen panels with apps, bookmarks, etc
2. Open Browser
3. Load a webpage
4. Tap 'star' icon to add a bookmark
5. Enter the name of the bookmark
6. Tap 'Add to homescreen'
7. Return to homescreen and try to find the bookmark

Expected: New panel with bookmark icon on it

Actual: No bookmark icon saved.

Comment 1

[Lukas Blakk [:lsblakk] use ?needinfo]

This doesn't sound like a blocker, though we should track it and get at least some notification to the user if that can be done in a low-risk fashion. Creating new panels seems like additional feature work - can UX and product teams weigh in here with v1.1 user story criteria?

Comment 2

[Zac C (:zac)]

I know regression range of 4-5 months is not very helpful but the Homescreen definitely used to automatically add a new panel in this case (back when if you had an Otoro you were part of the elite), which is where I have derived the Expected behaviour from.

I couldn't say if this functionality has regressed or was removed.

Comment 3

[Stephany Wilkes]

Changing flag from Jaime to UX team and marking UX-P? so we can triage and track this appropriately.

Comment 4

[Zac C (:zac)]

Just to add more information here: if you add a new app, either via Marketplace or via Everything.me then a new panel is created and the icon added to it so there is a clear precedent (and code) for this in Gaia.

This bug is specific to adding a bookmark from the Browser app.

Comment 5

[Bob Silverberg [:bsilverberg]]

This seems to be fixed on the build just released today:

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/765d296cff66
Gaia   e420d71c9528786621f176fb4ce67d291e0a530e
BuildID 20130501070205
Version 18.0

I will let zac test and close the bug if it seems to be resolved.

Comment 6

[Stephany Wilkes]

Clearing the UX-P? and needinfo for firefoxos-ux if this has already been implemented. Please flag us if additional UX work is needed.

Comment 7

[Peter Dolanjski [:pdol]]

If this has regressed, I'd suggest that we block on this.  No information to the user in such an expected behavior situation (which doesn't seem like such an edge case) seems quite broken.

Comment 8

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Patch

It works for me but there is a little visual defect that it fixed with the attached patch.

Comment 9

[Cristian Rodriguez (:crdlc)]

Although the patch is correct from my point of view, I would like you test [1], maybe, going to the current page these values are initialized correctly, so if we change the panning mechanism in the future we don't have splited code although I don't want to change anything about it in the future jejeje. Can you test it Vivien?

Thanks a lot

[1]

// If the new page is situated right after the current displayed page,
// makes it visible and move it to the right place.
  if (currentPage == pages.length - 2) {
    goToPage(currentPage);
  }
}

Comment 10

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Patch v2

And obviously you're right.

Comment 11

[Cristian Rodriguez (:crdlc)]

Comment on attachment 750557 [details] [diff] [review]
Patch v2

It works perfectly

Comment 12

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

https://github.com/mozilla-b2g/gaia/commit/8d4512eb9d796f2ba2d1cd79abeb9c7c3c5758b5

Comment 13

[Cristian Rodriguez (:crdlc)]

Nice! I didn't see this bug, great work