Closed
Bug 806745
Opened 13 years ago
Closed 13 years ago
Port test_bug497578.js to the new per-tab PB APIs
Categories
(Firefox :: Private Browsing, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: ehsan.akhgari, Assigned: marioalv)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/test/unit/test_bug497578.js
In order to port this test, the file needs to be copied to the same directory (perhaps with "_perwindowpb" appended to its file name), and then instead of setting privateBrowsingEnabled, we need to open a new private browsing window and then run the test on that window. Note that the original test should only be added to the list of test files in Makefile.in ifndef MOZ_PER_WINDOW_PRIVATE_BROWSING, and the new test file should be added to the list with the reverse condition.
| Reporter | ||
Comment 1•13 years ago
|
||
Removed this test from per-window PB builds:
| Reporter | ||
Comment 2•13 years ago
|
||
Updated•13 years ago
|
Assignee: nobody → marioalv.mozilla
| Assignee | ||
Updated•13 years ago
|
Status: NEW → ASSIGNED
| Assignee | ||
Comment 3•13 years ago
|
||
Hi Ehsan.
We have been investigating about this bug and we have found some difficulties for this migration
Right now we are thinking about two options
1. Keep this test as a xpcshell test, but removing the calls to nsIPrivateBrowsingService.
If we remove these calls, the test passes, but we can not simulate entering private mode.
Do you know if there's another way to simulate entering the new per window private browsing form an xpcshell test?
2. Migrate this test to a mochitest.
We've been working on the migration and made some attempts, but we noticed a couple of things:
- There are a lot of functions to be migrated to a browser/head.js file, taken from several other files in the test folder (shared.js, sharedUpdateXML.js and unit/head_update.js.in).
- After migrating all the needed functions for this test to work, we noticed that after the function standardInit() is called, the failed download is not reactivated and there's where our code fails.
The download / update files are being written to disk OK, but the update manager can not find the failed download and we are not sure why.
Can you please give us some guidance here?
Thanks a lot.
| Reporter | ||
Comment 4•13 years ago
|
||
Hmm. This test was originally added for bug 497578. The code which was causing that bug is long gone, and thinking about this, I don't think that this test is going to provide any value in the per-window world. Let's just call this WONTFIX and move on. Thanks for looking into this and sorry that it wasted your time.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
| Assignee | ||
Comment 5•13 years ago
|
||
This patch is our WIP for point #2. The line that fails is this:
JavaScript error: chrome://mochitests/content/browser/toolkit/mozapps/update/test/browser/browser_bug497578_perwindowpb.js, line 76: TypeError: gUpdateManager.activeUpdate is null
The gUpdateManager.updateCount is zero at that point.
Thanks.
| Reporter | ||
Comment 6•13 years ago
|
||
Like I said, don't worry about this. :-)
| Assignee | ||
Comment 7•13 years ago
|
||
Thanks for all your help.
Let's move on with more bugs then.
You need to log in
before you can comment on or make changes to this bug.
Description
•