php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #35875 IE event failure upon scheduling script
Submitted: 2006-01-03 03:52 UTC Modified: 2021-05-16 04:22 UTC
Votes:4
Avg. Score:2.5 ± 0.9
Reproduced:0 of 2 (0.0%)
From: csaba at alum dot mit dot edu Assigned: cmb (profile)
Status: No Feedback Package: COM related
PHP Version: 5.2.4 OS: WinXP Pro
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: csaba at alum dot mit dot edu
New email:
PHP Version: OS:

 

 [2006-01-03 03:52 UTC] csaba at alum dot mit dot edu
Description:
------------
My script brings up an instance of IE, and then it places onto IE a function that will execute one of the script's functions (within the script's environment).  This is a normal scenario usually achieved through com_event_sink in PHP.  However, I have implemented this independent of events.  I have both a VB and PHP version, both are working fine from the command line, thanks very much.

The problem is that when I run the PHP version using the scheduler (either AT or SchTask), I get an IE error IE right at the point that it tries to call back into the script (a permissions issue?).  The scheduled VB version works fine, and if I schedule PHP to invoke the VB version that works just fine, too.

Csaba Gabor from Vienna

Reproduce code:
---------------
<?php
$ie = new COM("InternetExplorer.Application");  // new IE
$ie->visible = true;
$ie->Navigate2("about:blank");         	    // empty DOM
while ($ie->readyState<4) usleep(10000);    // wait for IE
$window =$ie->document->parentWindow;
$window->execScript("window.doneP=false");  // init var

$oScript=new COM("MSScriptControl.ScriptControl"); 
$oScript->Language = "VBScript";
$oScript->AddCode('Sub EvtWrapper()
    CreateObject("WScript.Shell").Popup _
      "ScriptControl reached", 4, "WScript popup", 131120
    End Sub');

$oScript->AddObject ("mydoc", $ie->document);
$oScript->ExecuteStatement(
    'mydoc.onclick=GetRef("EvtWrapper")');
$window->execScript(
    "window.myfunc=window.document.onclick");

$window->setTimeout("window.myfunc()",100);

mypopup("At com_message_pump");
try { while (!$window->doneP) com_message_pump(500); }
catch (Exception $e) { popup ("In the catch"); }
mypopup ("Done with script");

function mypopup ($text) {
   $oWSH = new COM("WScript.Shell");
   $oWSH->Popup($text, 4, "PHP Popup", 131120); }
?>

Expected result:
----------------
I expect this script, schTest.php, to not error when it is scheduled with AT as:
AT 14:10 %comspec% "/K php c:\path\to\schTest.php"

In particular, just as when it is run directly, IE should come up, and then there should be two popups: "At com_message_pump" followed by "ScriptControl reached".  Once IE is dismissed, there should be two more popups: "In the catch" and "Done with script"

Actual result:
--------------
When SchTest.php is run directly (or via a .vbs invocation) then all four popups show normally.  However, when schTest.php is scheduled through AT, then there is an IE error saying
Line: 0
Error: Object doesn't support this property or method.

When I try the scheduling through SchTask (same results as with AT), then it is scheduled as NT AUTHORITY\SYSTEM (no password).  I'm the only user on my system and since I don't have a password, I haven't figured out how to schedule tasks to run under my user name.

I am happy to provide the corresponding VBScript code if it would be helpful.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-01-03 11:55 UTC] csaba at alum dot mit dot edu
I have some additional information on this problem.  If I schedule the php task using SchTasks as "Gabor", shown below, then the php script runs fine.  In order to be able to do this on my single user, no password system I must first allow Scheduled Tasks to be run without password as described here:
http://groups.google.com/group/microsoft.public.windowsxp.general/browse_frm/thread/c1b603be72394ee2/

Then, at the command window I type (on one wrapped line):
C:\phpApps>schtasks /Create /SC once /TN schTest /TR "php.exe c:\phpApps\schTest.php" /ST 11:23:00 /RU "Gabor"


Just to repeat the original problem:  There is a discrepancy when scheduling (as SYSTEM - the default for AT) the php task vs. the vbscript task to do essentially the same thing.  The php task errors when its created IE attempts to run code within the task while the vbscript task runs fine.  Both scripts run fine when run directly from the command window.

Csaba

PS.  The problem is also exhibited if I ask IE to call into PHP directly (via a PHP class) instead of directing it into a ScriptControl.  I illustrated the method shown above because it is the direct analogue of the standard VBScript approach, but I can also provide a "pure" PHP way.  However, in that case, when the script is scheduled as SYSTEM (via the AT command) the error is: Permission denied
 [2007-04-11 14:59 UTC] wharmby@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

Hi Csaba,
	Is this still an issue for you with the latest level of PHP ? 

I have taken your supplied testcase and corrected the  typo:

	popup ("In the catch")==> mypopup ("In the catch")

to get it to run from command line and it runs as you describe; 2
pop-ups before IE is terminated and 2 after. 

Next I scheduled it to run with AT command and again all was OK. I ran
it as both: 

AT 13:18 %comspec% "/K php <path.to.testcase>"

and 

AT 13:18 /interactive %comspec% "/K php <path.to.testcase>"

and both ran fine at the specified time; I just had to use Windows 
Task Manager in the first case to dispose of IE and so prompt the 3rd 
and 4th popups.

Next I scheduled it using schtasks. On my Windows XP system I do have a user-id & password and I scheduled the task in 2 ways:

schtasks /Create /SC once /TN schTest /TR "php.exe <path.to.testcase>" 
/ST 14:12:00 /RU "<computer name>\<id>"
  (and supplied password when promoted) 

and 

schtasks /Create /SC once /TN schTest /TR "php.exe <path.to.testcase>" 
/ST 14:15:00 /RU "System"

and again both times the script ran at the specified time with all 4
pop-ups. 

Can you please re-try with latest PHP snapshot on your system and let
me know the result.

Regards
	Andy 
 [2007-04-11 21:00 UTC] csaba at alum dot mit dot edu
Hi Andy,

  First, in case I haven't yet expressed appreciation for your examining the series of COM bugs I reported, a big THANK YOU to you.  I appreciate it very much.

  I am currently traveling and not in a position to do the testing that you asked.  Once I arrive back on about April 24, I will attend to carrying out the tests.

  Thanks,
  Csaba
 [2007-06-06 22:24 UTC] sniper@php.net
So, it's 7th of June, what about the tests? :)
 [2007-09-07 01:18 UTC] csaba at alum dot mit dot edu
Hi Andy, this is still happening in the same way as I originally reported.  This is with PHP 5.2.4.
Since we both have XP, I thought it might be my Norton Antivirus, but turning off the protection did not help.
It also happens when I place event handlers on IE (com_event_sink).

My php.ini settings for COM are as follows:
com.allow_dcom = true
com.autoregister_typelib = true
com.autoregister_casesensitive = false
com.autoregister_verbose = true
 [2017-10-24 03:31 UTC] kalle@php.net
-Status: Assigned +Status: Open -Assigned To: wharmby +Assigned To:
 [2021-05-03 11:35 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-05-03 11:35 UTC] cmb@php.net
Is this still an issue with any of the actively supported PHP
versions[1]?

[1] <https://www.php.net/supported-versions.php>
 [2021-05-16 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 03:01:27 2024 UTC