1529590 - Firefox restore has a strange behavior on (en-US) builds with a non-Ascii profile name if a different, ar build, is used and closed during this process

Status: NEW

(Firefox :: Session Restore, defect, P5)

Description

[Maria Berlinger [:mberlinger], Services QA]

Note

• need an en-Us Firefox build and an ar build
• unicode profile for en-Us build

Affected versions

• 65.0.1
• 66.0b9
• 67.0a1 (20190221093143)

Affected platforms

• mac OS 10.14
• Windows 10x64
• Windows 7x64
• Ubuntu 18.04x64

Steps to reproduce

1. Launch Firefox with a new profile using unicode character (on an en-Us build) (e.g. ⓴⚓⛓❁✿).
2. Open some random websites.
3. Leave the en-Us build open and open the ar build with another profile.
4. Close the ar build.
5. In en-Us build go to about:support and click the "Refresh Firefox..." button.
6. The about:sessionrestore page is displayed.
7. Choose "Restore only the ones you want" option.
8. Choose "Restore all windows & tabs" option.
9. Go to Library and check the Bookmarks section.

Expected result
7. Previous opened tabs are successfully displayed inside the table.
8. Previous opened tabs are successfully restored.
9. Standard Firefox bookmarks are displayed in English.

Actual result
7. Previous opened tabs are not displayed inside the table.
8. A blank page is opened.
9. Standard Firefox bookmarks are displayed in Arabic.

Regression range

• This is not a recent regression since I was able to reproduce on Firefox 65.0.1, I'll investigate further.

Additional notes

• On Windows 10x64, Ubuntu 18.04 x64, Windows 7x64 the about:sessionrestore has different behavior for step 7 the previous opened tabs are successfully displayed inside the table but one of them is in Arabic and for step 8 the about:support and privacy pages are displayed.
• On Nightly (20190221093143)I can't reproduce the issue because when you click the "Refresh Nightly..." button from about:support the panel gets blocked.

Comment 1

[Maria Berlinger [:mberlinger], Services QA]

Last good revision: 2016-11-01
First bad revision: 2016-11-02
Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?startdate=2016-11-01&enddate=2016-11-02

I think this is the bug 1305253 that regressed this behavior, but I'm not completely sure however, since I've made the regression manually.

Comment 2

[Julien Cristau [:jcristau] (back April 22)]

Old regression, wontfix for 65/66.

Comment 3

[Mike de Boer [:mikedeboer]]

This is a very obscure bug... you have to out of your way to create such a profile directory. It's also not clear that the bug you signified as regressing this feature is in fact the culprit. Could be, but only the assignee or reviewer of that bug could tell. Strictly, we'd need to be able to support this case. But I think the priority should be quite low. Nice find, though!

Comment 4

[Markus Stange [:mstange]]

(In reply to Maria Berlinger [:maria_berlinger], Release Desktop QA from comment #1)

Last good revision: 2016-11-01
First bad revision: 2016-11-02
Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?startdate=2016-11-01&enddate=2016-11-02

I think this is the bug 1305253 that regressed this behavior, but I'm not completely sure however, since I've made the regression manually.

I think it's extremely unlikely that bug 1305253 is responsible for this regression. Could you try to confirm the regression range again?

Comment 5

[Maria Berlinger [:mberlinger], Services QA]

(In reply to Markus Stange [:mstange] from comment #4)

(In reply to Maria Berlinger [:maria_berlinger], Release Desktop QA from comment #1)

Last good revision: 2016-11-01
First bad revision: 2016-11-02
Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?startdate=2016-11-01&enddate=2016-11-02

I think this is the bug 1305253 that regressed this behavior, but I'm not completely sure however, since I've made the regression manually.

I think it's extremely unlikely that bug 1305253 is responsible for this regression. Could you try to confirm the regression range again?

Markus, did you take a look at the other bugs from the pushlog I mentioned? It took a lot of effort to get this data and I doubt that I will get different results by bisecting the issue again, manually. Just to be clear, I was unable to use mozregression for this, because the issue is reproducible in very specific conditions that can't be simulated with the tool.

Comment 6

[Markus Stange [:mstange]]

I see. I took a look through the list but nothing jumped out at me - it's a long list and there are too many changes that might have caused this bug to make an educated guess.