we are using IE (which is the standard in our company), but we tried Firefox (not a standard) - same effect.
Our company is very strict with the IE standard - no chance to change to any other browser.
And, you are right, IE updates are happening in the background all the time. Maybe one of these updates
caused the problem.
Do you see any chance to fix the Filter problem?
Which IE version are you using?
What might help is to see what happens with the calls made to the database and see what error they report. It could be that you are getting an error page in HTML code instead of the filter HTML code.
If you have IE9 (or above): load the page, press F12 to bring up dev tools. Go to the network tab. Click "start capturing". Now in your page go to actions > filter. Stop capturing.
What interests you is the call here with method POST to WWV_FLOW.SHOW. Select that line and click "go to detailed view". Click the "Response body" tab. Take a look at it. Maybe best to copy the code and paste it into a file and view it in a browser (unsure if that works) or format the code.
Alternatively, just to debug this issue and if you do not have IE9 or above: get Chrome or get the Firebug addon for Firefox. Their tools are better suited.
Chrome: Press F12 to bring up the console. Open the Network tab. Click actions > filter. View the latest entry in the network tab that points to wwv_flow.show. Click it and it will open the details up. Now you can click the preview tab to see what is returned - which is handy when unformatted html is returned.
Firebug: Press F12 and go to the console tab. Now do the actions > filter. You'll see a line (or lines) pop up (POST GET GET eg). Select the POST to wwv_flow.show. Click the HTML tab and preview.
We are using IE 9 and followed your first approach ...
When opening the file with the saved HTML code the filter page appears, but with the message
"Internet Explorer restricted this webpage from running scripts or ActiveX controls. Blocked content"
So, do we have a too restricted IE 9 settings problem? Do you know which setting we have to change?
Thanks for your help.
- Go to the internet options of IE and check the security tab, see what it is set to. I'm not sure this is a related issue and might just be because you're trying to run that html in a seperate file. It'd be weird for this to be a security issue if you have no issue with newly-created IRs. Good to know that the filter html is there though. That html contains script tags but shouldn't be an issue (again, since newly created ones raise no error).
Maybe I went a bit overboard with the network capture - can you simply check the Console and Script tabs in the developer tools after you've done actions > filter. Any warnings or errors (red line)?
I'm taking some stabs in the dark here though!
I can see these error message under Console and Script tab:
SCRIPT5007: Unable to delete property 'maxDate': object is null or undefined
SCRIPT257: Could not complete the operation due to error 80020101.
I am far away from understanding the meaning and consequences of these messages?
That is ugly. I think this is an error from the widget.datepicker.js file where it tries to execute
and fails because the locale has not been instantiated. This locale instantiation should occur from 1 of the 2 script files added by the get filter call.
- To make sure the error is where it is I think: log in as developer, run the page. Enable debug. Do actions > filter. Go back to the browser developer tools and look at the maxdate error again. It should no longer say "desktop_all.min.js" for filename but a more specific file.
- When you capture traffic in the dev tools in ie (rerun it, start capture before clicking actions, stop capturing after you've clicked filter): what files does it mention?
For example, I get these:
/pls/apex/wwv_flow.show POST /l/libraries/jquery-ui/1.8.22/ui/i18n/oracle/jquery.ui.datepicker-en-us.js GET /l/libraries/apex/minified/widget.datepicker.min.js?v=4.2.2.00.11 GET
(The locale initializations are in that second file normally.)