In Loadrunner Truclient protocol while recording the web application Google Chrome/Firefox instances is opening in incognito mode but the issue is my application will not work incognito mode.
My application is working fine in only normal mode of Google Chrome/Firefox instances.
Could anyone please let me know during recording with truclient how to change the Chrome/Firefox instances from incognito mode to normal mode.
You already posted this question on the official product forum (https://community.softwaregrp.com/t5/LoadRunner-Practitioners-Forum/Urgent-Truclient-chrome-instance-is-opening-in-Incognito-mode/m-p/1624503) and got a response by the lead developer of the TruClient protocol.
His answer is:
TruClient runs the browser in Incognito/Privacy mode to allow separation of
Vusers during a load test.
This cannot be disabled or changed.
Perhaps you can elaborate on why your application is not working in these
modes, so we can try to find a workaround.
and then
Some browser features behave differently in privacy mode.
For example, IndexedDB cache mechanism is not implemented in Firefox
private mode [See the bug in Mozilla]
https://bugzilla.mozilla.org/show_bug.cgi?id=781982
From the error you mentioned, it seems this is related a similar browser issue.
As mentioned before, it is not possible to run TruClient in non-private mode.
Workaround: Run one full GUI Virtual User in a singular operating system instance. run one of these per business process on dedicated OS instances. Run the remainder of your load using API level (HTTP) virtual users.
I have been logged-in into stackoverflow in Chrome browser with my Google credentials and then I open stackoverflow in Firefox Developer Edition browser and tried to login again in Firefox with Google credentials. I have been automatically logged-in. I clicked to log out and after logout when try to login with Google credentials, I have been automatically logged-in again.
As per my knowledge, Firefox and Google chrome doesn't share the session.
So, I am curious to know whether this new FDE browser share session
with chrome or is it the feature of StackExchange?
No. Firefox/Chrome doesn't share sessions. Auto relogin is feature of Stackexchange. You can completely uninstall one of the browsers, clear cache and retry and this will still work.
Firefox/Chrome uses entirely different browser engines. Firefox based on Gecko and Chrome is based on Blink - each with it's own data storage formats. They may use sqlite, but Chrome still saves secure passwords with operating system security features like keystore in osx. Firefox saves password internally. Even if they wanted to, for data exchange both browser would need to arrive at a common data exchange formats with a LOT of security implications.
I developed an extension for my team with more than a dozen persons. And we used it internally. But some Windows-base-on colleagues now face a problem. When they update chrome to verson 37 and above, my extension is blocked by chrome, due to its not installing by chrome app store. Is there a cheap way to avoid this?
I had tried some methods. We don't want to change chrome into chromium or change their Windows into MacOS, Linux. And we want to update Automatically, so packaging on local is standby. Publishing in chrome app store is also a standby. Is there any other way?
Alternative deployment is available only if your computers are in a Windows domain. You can then use this documentation to set up distribution via Group Policy.
Other than that, no, you have to publish on the Web Store. It's $5, once, it's not that costly. You can set your item to be Unlisted, so that it's not possible to install it without knowing an explicit link, or you can even restrict it to an explicit list of Google accounts.
As a bonus, if you deploy to Web Store providing your packaging key, I think the extension will be turned back on automatically.
Is there a technical reason, why a Google Drive application must be installed through the Chrome Web Store (which severely limits the number of potential users)?
The reason that installation is required is to give users the ability to access applications from within the Google Drive user interface. Without installation, users would have no starting point for most applications, as they would not be able to start at a specific file, and then choose an application.
That said, I realize it can be difficult to work with in early development. We (the Google Drive team) are evaluating if we should remove this requirement or not. I suspect we'll have a final answer/solution in the next few weeks.
Update: We have removed the installation requirement. Chrome Web Store installation is no longer required for an app to work with a user's Drive transparently, but it is still required to take advantage of Google Drive UI integrations.
To provide the create->xxx behaviour that makes a new application document from the drive interface, and to be able to open existing documents from links, there must be some kind of manifest registered with Google's systems and some kind of agreement from the user that an application can access your documents and work with specific file types. There's little way around this when you think about the effects of not doing this.
That said, there are two high level issues that make for compatibility problems.
As the poster says, the requirement to install in the chrome store
severely limits the number of potential users.
But why? Why do the majority of Chrome Web Store applications say that they only work on Chrome? Most of these are wrappers to web applications that work on a range of browsers, yet you click through a selection and most display "works on chrome", aka only installs on chrome.
Before we launched our application on chrome we found that someone had created "xxxxxxx launcher" in the store, that simply forwards to our web app page. We're still wondering why it only "works on chrome". I suspect that some default template for the web store has:
"container" : "CHROME",
in it, which is the configuration option to say chrome only. That said, I can't find one, so I'm very confused why this is. It would be healthier if people picked Chrome because it's the better browser (which it is in a number of regards), not because their choice is limited if they don't. People can always write to the application vendor and ask if this limitation is really necessary.
The second thought is that a standardised manifest format across cloud storage providers would mean a much higher take up in web app vendors. Although, it isn't hugely complex to integrate, for example, with Google Drive, the back-end and ironing out the the details took over a week in total. Multiply that lots of storage providers and you have you lose an engineer for 2 months + the maintenance afterwards. The more than is common across vendor integration, the more likely it is to happen.
And while I'm on it, a JavaScript widget for opening and saving (I know Google have opening) by each cloud storage provider would improve integration by web app vendors. We should be using one storage providers across multiple applications, not one web application across multiple storage providers, the file UI should be common to the storage provider.
In order to sync with the local file system, one would need to install a browser plug-in in order to bridge the Web with the local computer. By default, Web applications don't have file I/O permissions on the user's hard drive for security reasons. Browser extensions, on the other hand, do not suffer from this limitation as it's assumed that when you, the user, give an application permission to be installed on your computer, you give it permissions to access more resources on the local computer.
Considering the add-on architectures for different browsers are different, Google first decided to build this application for their platform first. You can also find Google Drive in the Android/Play marketplace, one of Google's other app marketplaces.
In the future, if Google Drive is successful, there may very well be add-ons created for Firefox and Internet Explorer, but this of course has yet to be done and depends on whether or not Google either releases the API's to the public or internally makes a decision to develop add-ons for other browsers as well.
I am interested in filtering traffic comming into Chrome. I've seen WebRequest API and ignoring the fact that it's experimental it seems that you can't stop traffic since events are asynchronous.
I was also exploring the NPAPI plugins for filtering but it seems that they are plugins that need to be registered for particular content type.
Is there any other way for filtering and blocking incoming HTTP traffic in Chrome?
EDIT
I don't know if using a proxy would be a viable option. I am building a software that can be installed on a client machine and this software supports traffic filtering based on custom criteria for IE and FF. I would like to add Chrome support also. Proxy is a third-party app. How would I control it? User would also have to change it's network connection settings.