Apologies for the slightly vague question but I'm pulling my hair out. Since this update we have had numerous calls regarding printing from our web app. Our web app uses an iframe and we use css #media print to hide all but this iframe for printing purposes. Since the update the user receives an Error 404--Not Found instead of the actual page. It would seem from the network trace that IE creates a temp .htm file in the local directory like D3CD911.htm, it then downloads css/js resources and then finally it makes this call /D3CD911.htm. This is making a call to www.mywebsite.co.uk/D3CD911.htm. This obviously does not exist on the website so the 404 is returned.
I struggling to find a pattern to the problem and it doesn't seem to be affecting other public sites. I think the issue is with window.print() method. I can semi reproduce it here at https://www.primefaces.org/showcase/ui/misc/printer.xhtml. If you click the print button you will get the error. Although this is using the jqprint javascript function if you then use the browser print button it also fails.
Any guidance would be much appreciated.
andyfinch, you're a genius! The following code appears to work for a print button contained within a frame:
function Print() {
if (document.queryCommandSupported('print')) {
document.execCommand('print', false, null);
}
else {
window.parent.<framename>.focus();
window.print();
}
}
Update:
Microsoft have now released a patch: Microsoft IE patch
Just wanted to summarise the workarounds I've found and which have been posted here.
1) If you are using your own print button change to use document.execCommand('print', false, null);. Test support using document.queryCommandSupported('print') and call window.print() if not supported (Prob just Firefox)
2) Use Print Preview. Additionally select the part of the page to print, right click and select print preview. Then select As selected on screen.
3) Use another browser like Chrome
4) Uninstall the update
5) Wait for Microsoft fix. Their KB page KB Link has been updated with this as a known issue. Therefore you assume a fix is on the way.
andyfinch's workaround is also working for us. Thanks Andy!
MS has flagged this issue with "WON'T FIX" (6/15/17): https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/12349663/ Update: that flag might just indicate that it's not an issue with MS Edge so it won't get fixed by the Edge developers.
Installing KB4021558 breaks printing from our website (the pages are blank, the footer shows some variant of "res://ieframe.dll/i273gyew.htm"). Uninstalling it restores printing functionality.
KB4021558 is also included in KB4022719, KB4022725 and KB4022727.
I found a workaround: if the iframe you're trying to print is visible, right click on it and choose Print preview... instead of Print... from the context menu. The preview seems to be printable (but may show only part of the frame contents).
Also, for the record, the problematic 64-bit Win7 update is KB4022719.
MS released updates yesterday (June 27th) that address it for Windows 10:
This non-security update includes quality improvements. No new
operating system features are being introduced in this update. Key
changes include:
• Addressed an issue introduced by KB4022715 where Internet Explorer
and Microsoft Edge printing from a frame may result in 404 not found
or blank page printed.
Links:
Windows 10 (Initial Release - Build 10240)
KB4032695 - Build 10240.17446
Windows 10 Version 1511 (Initial Release - Build 10586)
KB4032693- Build 10586.965
Windows 10 Version 1607 (Initial Release - Build 14393)
KB4022723 - Build 14393.1378
Windows 10 Version 1703 (Initial Release - Build 15063)
KB4022716 - Build 15063.447
Source/More info
I grabbed them from the Windows Update Catalog today, to use with WSUS.
Heres the workaround I have been using for this in IE 11:
Right click frame and choose select all, or [ctrl + A] in the frame
Right click and choose print preview
There should be an option in your preview for "As selected on screen". Choosing this allowed me to print everything in the frame.
We were having multiple frames in the print screen and calling document.execCommand('print', false, null); could not fix our issue. Instead window.parent[frameName].document.execCommand('print', false, null); fixed it.
Related
I'm running a set of automated UI tests using Appium/Winappdriver on Windows 10. The test framework is compiled in Visual Studio 2017 using mstest.
The problem that I am having is with tests that use a right-click to open a context menu, then select an element from the resulting menu. Locally, it works. It also works on our remote CI/CD machine. However, it does not work for the other two developers on the project, and we've spent two business days fruitlessly trying to figure out why.
We have the same Windows version (Windows 10, version 1903), we have the same Visual Studio 2017 (we also tried it with 2019, no luck), we have the same monitor resolution (1920 x 1080), we are targeting the same .NET framework (4.72), we have the same WinAppDriver, etc.
Everything else works just fine. But when the UI Test reaches that context menu, the test fails with the error "An element could not be located on the page using the given search parameters."
I used the WinAppDriver UI Recorder to find the XPath for the element. We also used it on the other user's machine and confirmed that, as far as the UI Recorder is concerned, the path is identical on both machines.
The specific call that fails:
Session.FindElementByXPath("/Pane[#ClassName=\"#32769\"][#Name=\"Desktop 1\"]/Menu[#ClassName=\"#32768\"][#Name=\"Context\"]/MenuItem[#Name=\"" + itemName + "\"]");
The WinAppDriver call on my machine (success):
{"using":"xpath","value":"/Pane[#ClassName=\"#32769\"][#Name=\"Desktop 1\"]/Menu[#ClassName=\"#32768\"][#Name=\"Context\"]/MenuItem[#Name=\"New Location\"]"}
HTTP/1.1 200 OK
Content-Length: 125
Content-Type: application/json
{"sessionId":"8970FDC1-E869-4304-A87D-D8F2CB711EA2","status":0,"value":{"ELEMENT":"42.856234.4.-2147483646.8140.18614751.1"}}
and the same call on the other user's machine (fail):
{"using":"xpath","value":"/Pane[#ClassName=\"#32769\"][#Name=\"Desktop 1\"]/Menu[#ClassName=\"#32768\"][#Name=\"Context\"]/MenuItem[#Name=\"New Location\"]"}
HTTP/1.1 404 Not Found
Content-Length: 139
Content-Type: application/json
{"status":7,"value":{"error":"no such element","message":"An element could not be located on the page using the given search parameters."}}
Again, everything else works. Other UI tests that don't use the right-click context menus work just fine. It's only this particular area that fails.
What I've tried so far:
Using Thread.Sleep to force a long wait before making the call
Wrapping the call with a DefaultWait and polling it over a period of several seconds to see if the element becomes available during that time.
When the "An element could not be located" is thrown, retry up to a set number of times to find the element.
Lots and lots of double-checking to make sure we're both on the same version of the code, same libraries, same nuget packages, etc.
Trying a much broader locator ( Session.FindElementByName(itemName); )
The biggest head-scratcher is that when we check with UI Recorder, the element is there. When we check on my machine or the remote build machine, WinAppDriver can find it normally. But for some reason WinAppDriver can't find it on my coworker's machines.
This is a peculiar issue indeed.
I'd like to rule out the XPath selector as a potential problem here. Based on your syntax, it looks like you are using an absolute XPath. These can be extremely brittle depending on the circumstances. Not saying it's the root problem, but I would like to try a different selector to rule this out.
{"using":"xpath","value":"//MenuItem[#Name=\"New Location\"]"}
Using relative // notation tells your path to look anywhere on the page, rather than following a specific path down to the element itself.
Give this a try, and let me know if it helps at all.
For my application context menu is listed out of the DOM of actual application in inspect.exe. So switching back to desktop session after selecting the context menu worked fine for me.
var regressionChannelRow = labelProcessorSession.FindElementByName("5000");
Actions action1 = new Actions(labelProcessorSession);
regressionChannelRow.Click();
action1.ContextClick(regressionChannelRow).Perform();
Now creating a desktop session to get the "Stop" option from the context menu
AppiumOptions appCapabilities = new AppiumOptions();
appCapabilities.AddAdditionalCapability("app", "Root");
WindowsDriver<WindowsElement> desktopSession;
desktopSession = new WindowsDriver<WindowsElement>(new Uri("http://127.0.0.1:4723"), appCapabilities);
below is the context menu option which I need to select, remember to use desktop session here
var stopService = desktopSession.FindElementByName("Stop");
stopService.Click();
I've just replicated this issue. I was working on a test that I wrote last week, which was now getting stuck trying to find the context menu from a desktop session. I tried using various XPaths, searching by class name or just name, but it didn't seem to make any difference.
Eventually I tried closing Spotify, and that solved the issue! If you're experiencing this problem then try closing every application window possible.
When I send "Test" to a textbox the web page displays TTeesstt in the texbox.
Even though the web form displays the double characters it appears what is actually submitted to the web app is only the original text.
When I ran my test using IE 8 the text "Test" was inserted once.
When I upgraded to IE 11 the text was inserted very slowly. This problem was discussed here.
I was trying to solve the slow Sendkeys problem and was playing around with my code to programmatically use IE or Chrome. I've backed off that code to just trying to use IE directly (InternetExplorerDriver class).
I've downloaded and installed all IE 11 cumulative updates.
I saw a post in Kaspersky labs forums about the double character problem. The posts seemed to indicate the problem is related to IBM Trusteer. I do have Trusteer installed on my personal laptop. However, the problem is occurring on a remote computer. I login to the remote computer via a VPN. While not 100% sure I don't think the remote computer has Trusteer.
Environment:
Windows 7 64-bit
InternetDriverServer 3.8.0.0, 32-bit
IE 11.9600.1886IS, Updates KB4052978
Selenium
I had this problem also. I was able to fix it by adding an option to my IEDriver in my selenium code. The option to add is:
ieOptions.EnableNativeEvents = true;
Unfortunately, that slowed my text-entry to about 1 character every five seconds. I was able to fix that by adding RequireWindowFocus = true.
My constructor now contains this code:
if (DriverType.IsType<InternetExplorerDriver>())
{
var ieOptions = new InternetExplorerOptions { IgnoreZoomLevel = true,
EnableNativeEvents = true, RequireWindowFocus = true};
Driver = new InternetExplorerDriver(ieOptions);`
}
For those who has Selenium-Serenity
Thanks to Joshua I found solution to add in serenity.properties
serenity.driver.capabilities=nativeEvents:true;requireWindowFocus:true;
I've started a new React Native project and I keep getting the following warning:
Remote debugger is in a background tab which may cause apps to perform slowly. Fix this by foregrounding the tab (or opening it in a separate window).
It's a bit annoying so I wanna know how I can get rid of it? I'm running the debugger in Chrome and I moved it to a seperate window but it did not help.
If you have the Maintain Priority checkbox in the debugger window, try enabling it before you jump to any of the solutions below.
To get rid of the warning in your whole project add the following to your outermost Javascript file (most of the time that's index.js for React Native)
for react-native v0.63+:
Use LogBox:
https://reactnative.dev/docs/debugging#logbox
LogBox.ignoreLogs(['Remote debugger']);
for react-native v0.57 - v0.62:
import { YellowBox } from 'react-native';
YellowBox.ignoreWarnings(['Remote debugger']);
Reference this from the official React Native docs:
https://facebook.github.io/react-native/docs/debugging.html
react-native v0.56 or below:
Add the following early on in your code:
console.ignoredYellowBox = ['Remote debugger'];
Easy, simple and specific to that error. Works for me. Can substitute for any text you want.
this solution is work for me
open/move http://localhost:8081/debugger-ui (default path for remote debugging) on the separate window
maybe that could help :)
You can use React Native Debugger available at https://github.com/jhen0409/react-native-debugger It is a standalone app for debugging React Native apps during development.
Move http://localhost:*****/debugger-ui on the separate window.
Restart Remote JS Debugging.
For me warning went away by checking Maintain Priority Checkbox!
It is because of number of tabs are opened in the browser with React Native Remote Debugger UI tab. I also faced the same issue.
To overcome this warning message you can use any one method from the following:
Open an incognito tab then paste http://localhost:8081/debugger-ui on address bar and press ENTER. Finally reload the app (Command+R).
Close all the tabs in the browser. Keep only 1 tab opened then hit http://locahost:8081/debugger-ui then reload the app (Command+R).
As mentioned by #jakeforaker in one of the comment. The warning went away by simply opening the remote debugger in a separate window instead of a tab in your existing window of your browser (you have to reload your simulator though).
As the warning is saying keeping the remote debugger in the same window as other tabs
may cause apps to perform slowly
So i think simply suppressing warning as mentioned by #kjonsson:- console.ignoredYellowBox = ['Remote debugger']; doesnt seem to be best solution.
Since this commit in March 2017, you can enable the Maintain Priority checkbox. When enabled, it silently plays a base64-encoded .wav file to prevent the debugger's browser tab from entering low-power mode, which can affect websocket performance. This will effectively prevent the warning you describe.
This issue was resolved when I closed all open Chrome windows and started the Remove Debugging again. I had previously had open Chrome windows, so it 'seems' that having them open kills performance.
I think the accepted answer is no longer accurate (at least for React Native v0.57+).
The correct code is now:
import { YellowBox } from 'react-native';
YellowBox.ignoreWarnings(['Remote debugger']);
Reference this from the official React Native docs:
https://facebook.github.io/react-native/docs/debugging.html
I am on Macbook. I fixed this issue by bringing the Debugger window on main desktop, rather than on having it on separate desktop which it thinks is in "Background".
I had the same issue pop up yesterday. Googling it led to this Stack Overflow post. In one of the response (by adriansprod), he suggested:
Chrome debugger in it's own window fixes. But annoying problem
It is likely that your React Native debugger is not in its own Chrome browser window but in a Chrome browser tab. Pulling it out as its own window, as adriansprod suggest, fixed this for me.
The (very annoying) error message is handled by debuggerWorker.js, which sadly doesn't include any configuration options to turn off the message. So for the time being there are no ways you can configure your application to disable the message.
The related code is outlined below (original licence applies):
var visibilityState;
var showVisibilityWarning = (function() {
var hasWarned = false;
return function() {
// Wait until `YellowBox` gets initialized before displaying the warning.
if (hasWarned || console.warn.toString().includes('[native code]')) {
return;
}
hasWarned = true;
console.warn(
'Remote debugger is in a background tab which may cause apps to ' +
'perform slowly. Fix this by foregrounding the tab (or opening it in ' +
'a separate window).'
);
};
})();
As you see, no configuration options are used, the whole thing is scoped off locally (see the above repo link for further details).
I also have faced with same issue about one week ago and finally i have found solution that works excelent for me
It called reactotron, you can find it here - https://github.com/reactotron/reactotron and you can use it to:
* view your application state
* show API requests & responses
* perform quick performance benchmarks
* subscribe to parts of your application state
* display messages similar to console.log
* track global errors with source-mapped stack traces including saga stack traces!
* dispatch actions like a government-run mind control experiment
* hot swap your app's state
* track your sagas
I hope my post was helpful and you never will faced with this tedious warning .
Good luck
I use this in index.js
if (__DEV__) {
console.ignoredYellowBox = [
'Remote debugger',
'Warning: isMounted… is deprecated',
'Module RCTImageLoader'
];
}
I had minimised the "http://localhost:8081/debugger-ui/" window. Just opening it up (un minimising), and reloading the app removed the warning.
there might be chances that Another debugger is already connected to packager.
so close your terminal and debugger google chrome.
if you are using visual studio's package manger then don't start package manager by Mac/other os terminal command.
so close all terminal and stop on going package manger and google chrome debugger.
start the process again.
Similar to Akshay Vijay Jain, mine went away by ticking this box!
I am brand new to odoo, just installed version 9 and made a module 'aidentest' using
.>>python odoo.py scaffold aidentest addons
That created the aidentest module in the addons folder. Uncommented everything in the autogenerated files
but when I went to check out my 'Hello World' page at
http://localhost:8069/aidentest/aidentest
I got a 404 not found
So I went to apps to try and load my module, but I could not find it.
Does anyone know what I need to do on Odoo 9 to load up and start coding my custom module?
Briefly: You have to activate developer mode by going to Top right menu>about>activate developer mode
I had basically given up, and was mindlessly clicking about when I hit the 'About' link on the generic-whiteguy dropdown. I had to actually stop thinking before I was able to locate the completely senseless place where they put the thing I need.
The About modal window popped up, and in it was an activate the developer mode button
Some things changed immediately, but I still couldn't find my custom module.
Then I walked away, came back and when I returned I had some auto-generated emails (new things had loaded - slowly). Did this mean that maybe my module had also become accessible? I checked, and sure enough, there it was.
ZERO DOCUMENTATION about this
Please check the config file.Then send the last error it has.
I ported some objective-c/CoreGraphics code that takes a screenshot of multiple monitors but it's not working. The jsctypes guys won't be able to help because the section is just me answering questions lol
The objc/cg code is from here: https://stackoverflow.com/a/28247749/1828637
My jsctypes type/struct/declares are here: https://github.com/Noitidart/NativeShot/blob/mac-troubleshooting/modules/ostypes_mac.jsm
The jsctypes port is here: https://github.com/Noitidart/NativeShot/blob/mac-troubleshooting/modules/workers/MainWorker.js#L443-656
And the last line is line 643 which causes the crash:
var rez_writeToFile = ostypes.API('objc_msgSend')(data, ostypes.HELPER.sel('writeTofile:atomically:'), myNSStrings.get(OS.Path.join(OS.Constants.Path.desktopDir, 'full_ss.png')), ostypes.CONST.YES);
This coincides with the objectivec of
[data writeToFile:#"/tmp/screenshot.png" atomically:YES];
except i changed path to ...desktop/...png
I wrote to sepearte gists, to align the lines in text diff software to make sure I did everything.
Here is objc/cg: https://gist.github.com/Noitidart/8affcd8bee60d22dcb52
and here is jsctypes: https://gist.github.com/Noitidart/3d4a4e8df625dbea8cc1
I dont think i missed anything i dont know why it crashes on that final line
Do any of the ObjC/CG people see any type definition that is wrong or something that I missed (for example the ObjC code uses compound statments I'm not sure I understood/translated them correctly in the port).
Wowww so after struggling for like some hours then posting this I realize it right away haha
Casing typo in selector!! I had writeTofile:atomically instead of writeToFile:atomically!
If anyone would like to test this out, it's a simple firefox addon test case.
Install an addon that allows installing addons from github repos from here: https://addons.mozilla.org/en-US/firefox/addon/github-extension-installer/
Go to commit on this branch that works here: https://github.com/Noitidart/NativeShot/tree/f5f2e8606d3c5c657e901239d3ceb8c8c79a4494
Then click the "Add to Firefox" button at bottom right, below the "Download Zip" button
Click on the toolbar button icon that gets added to firefox, as seen in this screenshot: http://i.imgur.com/n7lSxje.png
Check desktop you now have a single png file with a screenshot of all the monitors, huge props to #KenThomas!