STR: - used a mock distribution file and test custom bundle that Margaret made for me (partner confidential specific) - clean profile as a result - the two preloaded bookmarks were pinned (as expected) with dominant favicon colours in the thumbnail pic (as expected) upon startup - tapped onto one of the preinstalled thumbnails and waited for the website to load - going back to the thumbnails page, you can see that the webpage has been added as per the top sites algorithm below the preinstalled sites and the website picture comes up - BUT the preinstalled thunbnail didn't change Expected: the preinstalled thumbnail modifies its picture from the favicon to the website shot Actual: the thumbnail remained the favicon even after the user visited the site

Karen: which version? Note: if the URL you eventually hit is not the exact same URL that's pinned, you'll get two entries. They're two different pages, with two different thumbnails (or no thumbnail in the former case). See Bug 934030, which isn't fixed anywhere. Workaround: make sure the pinned URL is the URL of the final page.

Huh. That is likely what it's doing then. Given that the name is pulled in from the bookmarks list - and we wouldn't want a super-long URL in the bookmarks screen - is there something that can be done? Like fix the bug you referenced in comment 1? :)

(In reply to Richard Newman [:rnewman] from comment #1) > Note: if the URL you eventually hit is not the exact same URL that's pinned, > you'll get two entries. They're two different pages, with two different > thumbnails (or no thumbnail in the former case). Yes. If possible, we should ask partners to give us URLs that won't redirect, since it's actually kind of silly to pin a site that will always redirect. We have also talked about supporting including thumbnails as part of the distribution, but we'd have to figure out the best way to store/retrieve that big piece of data (right now favicons are just data URIs, but thumbnails would have super huge data URIs). (In reply to Karen Rudnitski [:kar] from comment #2) > Given that the name is pulled in from the bookmarks list - and we wouldn't > want a super-long URL in the bookmarks screen - is there something that can > be done? The title for the bookmark is something we hardcode as part of the distribution, and plenty of URLs are long enough that they get ellipsized anyway, so I don't think that should be a huge deterrent.

Ok, so reading comment 3, we ask the partner to provide a URL (however long it is) that won't redirect, as well as a friendly title name to hide the ugly long URL. Right?

We should be including a bookmark title regardless. ("Firefox Support") And yes, non-redirecting URL -- which you might be able to get yourself by just looking at where it redirects, but it's worth mentioning to the partner. This will be particularly difficult if the URL ends up redirecting to include the locale or somesuch. It's possible to get that to work without redirecting (there are HTTP headers that do the right thing), but I'd expect some pushback.

Ok. So in this one specific case, I think we should be ok and I'll just provide some more specific parameters to the partner (and I don't think we'll get into a locale-specific issue in this case). But I did want to ensure that we've looked at the others so that we don't come across the same issue. Is this a QA needed or a look into the distribution files themselves to see what's been requested vs the actual output?

Keep in mind that you can actually include different URLs/titles for different locales: https://wiki.mozilla.org/Mobile/Distribution_Files#Bookmarks