ericmckean / chromedriver

Automatically exported from code.google.com/p/chromedriver
0 stars 0 forks source link

Regarding #611, "prefs" should only be overwritten if specified. #1024

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
We have a case where we use a custom profile for tests and since v12 
chromedriver overwrites the preferences regardless. It should only do this if 
we specify "prefs" under "chromeOptions".

Related issue: https://code.google.com/p/chromedriver/issues/detail?id=611

Original issue reported on code.google.com by mbpp1...@gmail.com on 30 Jan 2015 at 11:12

GoogleCodeExporter commented 9 years ago

Original comment by andrewch...@chromium.org on 30 Jan 2015 at 6:22

GoogleCodeExporter commented 9 years ago
The rule  is new specified  "prefs" under "chromeOptions" will overwrite 
existing 
preferences,  otherwise, it will not change it. 
do you have test case that if we can reproduce it?

Original comment by andrewch...@chromium.org on 30 Jan 2015 at 6:29

GoogleCodeExporter commented 9 years ago
Thanks for the prompt feedback! I noted that when we specify "user-data-dir" 
and the directory doesn't exist chromedriver creates a partial profile 
directory between starting the session and invoking chrome. The issue is that 
we use a special "binary" path that runs a script that copies one of our 
template profiles (if not exists) before invoking chrome and it was complaining 
that the directory already exists. In this case OK because we are now 
overwriting any file. I will check if any preference is being changed when it 
exists and get back to you, if not we can close the issue. In any case I think 
chromedriver should not do anything if the "prefs" clause is not passed to 
avoid unnecessary overhead.

Original comment by mbpp1...@gmail.com on 31 Jan 2015 at 11:13

GoogleCodeExporter commented 9 years ago
Let me how if everything work the way it should be.

Original comment by andrewch...@chromium.org on 2 Feb 2015 at 6:22

GoogleCodeExporter commented 9 years ago
So I did more tests and when the profile directory exists it seems no files are 
changed by chromedriver or if changed it keeps the same content (I compared 
some files before/after). You can close but note, when the profile doesn't 
exist chromedriver is still creating a basic one even if we don't specify 
"prefs". I think you should consider skipping this whole process if "prefs" is 
not specified to save time and resources.

Original comment by mbpp1...@gmail.com on 7 Feb 2015 at 2:46

GoogleCodeExporter commented 9 years ago
If you don't specify "prefs",  chromedriver will provide a default profile as 
temp
this temp dir will be removed  when session closed.   you should not notice the 
exist of temp dir.

Original comment by andrewch...@chromium.org on 9 Feb 2015 at 6:51

GoogleCodeExporter commented 9 years ago

Original comment by samu...@chromium.org on 21 Feb 2015 at 12:18

GoogleCodeExporter commented 9 years ago
But we use a custom data directory via "use-data-dir". In fact, before invoking 
Chrome we copy our template to this data directory. We override the "binary" 
parameter to point to a script that checks if the data directory exists before 
invoking Chrome and at this point the directory is being pre-created by 
Chromedriver even if we don't pass "prefs". Also, we see sometimes the error 
"failed to write prefs file" (code 13), not sure if it is because we upgraded 
Chromre recently (40.0.2214.115 m) and there is some profile mismatch or it is 
related to this functionality.

Original comment by mbpp1...@gmail.com on 23 Feb 2015 at 2:25

GoogleCodeExporter commented 9 years ago
Getting in many tests the error:

unknown error: failed to write prefs file

I cannot determine any logical pattern, it happens in about 5% of the time and 
no specific test or profile. One more reason not to touch the profile if no 
"prefs" was specified. Versions:

Chromedriver: 2.14
Chrome 40

Original comment by mbpp1...@gmail.com on 6 Mar 2015 at 5:48

GoogleCodeExporter commented 9 years ago
Complementing, Windows 2008 R2 via Remote Desktop.

Original comment by mbpp1...@gmail.com on 6 Mar 2015 at 5:49

GoogleCodeExporter commented 9 years ago
since it happens randomly in about 5% of the time  

1. can you do the same process in window 7(must use same chrome and 
chromedriver)?  - to see if it happen only in Windows 2008

2. Can you modify your scripts - copy prefs file before any write, and record 
the status.  compare the files  when error 

3.  find a way to get OS detail messages about any write error - this is the 
easiest 
   way to find out the problem.

Original comment by andrewch...@chromium.org on 6 Mar 2015 at 8:02

GoogleCodeExporter commented 9 years ago
In Windows 7 I was not able to see this error, I will try to get pre/post 
versions of the preferences file in Windows 2008 when the error happens now. As 
for OS errors I am not seeing any, nor in Windows Events. It seems to happen 
when there is concurrency, when multiple tests are being executed under 
different profiles (3+), my guess is that the error is related to some 
wait/locking event in chromedriver. I will test more.

Original comment by mbpp1...@gmail.com on 10 Mar 2015 at 2:26

GoogleCodeExporter commented 9 years ago
some people use chromedriver in Selenium grid/node which test many devices 
concurrently, and have not report the problem. In Windows 7,  did you do the 
same testing as in Window 2008?

Original comment by andrewch...@chromium.org on 10 Mar 2015 at 6:17

GoogleCodeExporter commented 9 years ago
I don't use Selenium, I implemented the protocol myself. I use chromedriver 
running in a Remote Desktop session (not service). Then I start several tests 
in parallel. I did the same test in Windows 7 and cannot replicate as I see in 
Windows 2008. The test I did was to start 10 sessions at the same time. I still 
cannot define a pattern or condition, it happens sometimes. Now there is only 
one difference between the Windows 7 and Windows 2008 tests, the Chrome 
version, one is 41 and the other 40. I will try to upgrade to do more tests.

Original comment by mbpp1...@gmail.com on 11 Mar 2015 at 12:01

GoogleCodeExporter commented 9 years ago
I upgraded to Chrome 41 and now I have another problem, not only "error writing 
prefs file" but also some pages loading forever and I cannot even stop or open 
any other tab. If a close the page Chrome continues to run on the background 
and the only way to stop is to kill the process. Does it have to do with the 
new DevTools enhancements in Chrome 41?

Original comment by mbpp1...@gmail.com on 12 Mar 2015 at 8:15

GoogleCodeExporter commented 9 years ago
So I downgraded to Chromediver 2.10, all tests executing fine with Chrome 41 
without the "prefs" error and the freeze. I will keep one server with 2.14 and 
41 to do more tests. The "freeze" error is specific to Chrome 41 and 
Chromedriver 2.14. The "prefs" issue, would be nice if nothing is 
done/written/overwritten if none is passed, if I can suggest as enhancement for 
speed reasons and to avoid the "error writing prefs file" issues.

Original comment by mbpp1...@gmail.com on 12 Mar 2015 at 10:40

GoogleCodeExporter commented 9 years ago
I don't have Windows 2008.  if you can focus in window 7 will be more helpful.
let's make sure testing for window 7 is clean.

Original comment by andrewch...@chromium.org on 12 Mar 2015 at 11:45

GoogleCodeExporter commented 9 years ago
I am still not able to simulate this in Windows 7, only Windows 2008 but I can 
see that it happens when we execute 4+ parallel tests. The issue is that I 
cannot yet identify some pattern, it can run fine in parallel for 30 minutes 
and then suddenly it raises error code 13. What are the possible conditions for 
this error? Since we use different profiles via "user-data-dir" it is clearly 
not a file sharing issue. Can it be maybe some temporary file being generated 
and there we have a sharing issue? In any case I will continue doing more 
tests, I am now creating a custom script to simulate in Window 7 the same 
environment workload we have in Windows 2008 (our production environment).

Original comment by mbpp1...@gmail.com on 6 Apr 2015 at 7:06