Can Chromium features that are normally turned on via switches be turned on programatically after starting up? - electron

Is there a way to use Chromium switches after starting it up, or must they be enabled on start up? For example, can switches be passed to the renderer processes, or just to the main process?
I want to turn on paint flashing in Chromium (actually in my Electron app which runs on top of Chromium).
Devtools has a checkbox that turns this on, but I want to be able to turn this on without devtools, and after the app has started.
I know there's a show-paint-rects flag I can use:
chrome.exe --show-paint-rects
In my Electron app, I would need to use app.commandLine.appendSwitch:
app.commandLine.appendSwitch("show-paint-rects");
I also found a ui-show-paint-rects flag that lives in something called the "compositor," but that may be irrelevant for me.
Both of these work, but since Chromium uses a multi-process architecture, I'm hoping that there's a way I can specify that switch, or otherwise, turn on a feature in one process and not have to specify it at startup.
Is there a way to do this in Chromium? (Would be ideal to do this in Electron, but I'm not counting on it)

Related

Vaadin: How do I get rid of vite?

The description of "Vite" was tempting and I was stupid enough to enable this new feature. Since then I am stuck with endless UI recompile loops! I.e. each time after I logged into my application the frontend gets recompiled AGAIN and the application restarts. ||-(
Disabling Vite in the lower right control-dialog is not accepted, it remains activated. How do I get rid of this unbaked feature again?
This is using Vaadin 23.1.7 and Java 17.
In Vaadin 23.1 you can remove the feature flag by deleting it from src/main/resources/vaadin-featureflags.properties.
Note that Vaadin 23.2 uses Vite by default. If you want to continue using Webpack going forward, you need to instead add this feature flag to the properties file:
com.vaadin.experimental.webpackForFrontendBuild=true

Appium works very slow on screen having dynamic mobile elements

I am working on automating an Android app. We have a screen that has a table wherein the cell values keep on changing in seconds. I have observed that it takes more than a minute for AndroidDriver to execute a single action.
I have read on some other forums about this and got to know that this is how the UiAutomator2 works and it has nothing to do with Appium. UiAutomator2 waits for elements to come to a static state and then performs the actions.
Since the dynamic elements on the screen are unavoidable, is there any workaround for this to make Appium scripts execute with good speed? Let me know what you all think of this. I will really appreciate your comments on this. Thanks.
Yes, that is right. It has nothing to do with Appium itself, but with UiAutomator. UiAutomator takes accessibility snapshots only when the application is in idle mode and the framework itself is not optimized for cases when there are constant changes in the page view. As a workaround, try to play around with waitForIdleTimeout such as setting it to zero or try with setting the disableWindowAnimation to true in the desired capabilities.
You could also try with running the following commands:
adb shell settings put global window_animation_scale 0
adb shell settings put global transition_animation_scale 0
adb shell settings put global animator_duration_scale 0
As a last resort, you could ask for the developers to provide you with a special build that has the animations removed in the source code.
I had the same issue, my specific problem was that the mobile app had a timer in the UI, that was changing its value every second.
Looks like the driver was waiting for the DOM to become idle, so it was SUPER slow because of that.
This simple command fixed the issue for me:
# Python code
driver.update_settings({"waitForIdleTimeout": 0})
Additional references:
https://appium.io/docs/en/commands/session/settings/update-settings/
https://github.com/appium/appium/issues/14155

Is Start (Dart framework) autoreload on the server side?

Is start (Dart server side framework) auto-refresh when one of our source code changed (just like PHP)?
Is bulls_eye, bloodless and express too?
or if they are not, is there any Dart server side framework that able to do that (edit code, then test on the browser, without needing to restart the dart/server program)?
Currently this is not yet possible in Dart. If you change the code you have to restart the app.
I wouldn't expect this to work anytime soon.
A main feature to make this possible is to manipulate the code at runtime. This is planned but as far as I know not yet started.
EDIT
The above mentioned feature is necessary when you want code to be updated without loosing the current state of the application but that is usually not so important on the server because it should be (mostly) stateless anyway.
In Dart there's no need to restart the server app when only the client part changes.
If you really just want to restart the entire server when the code changes you should be able to do that by yourself. Create a console app that loads the server app into an isolate (spawnUri) and watch the source directory for file changes. In the case of a file change shutdown the server-app-isolate and create a new one.

How can I stop executing .wlua files?

Is it possible to force stop a .wlua file? I figured that I would have to use the Lua Command Line to do this, but I can't seem to find out how to stop them.
If it's possible, how can it be done?
Because wlua.exe doesn't open the console window (that's the purpose) and you can't send Ctrl-C, the only way to terminate such application is to use Processes window in Task Manager. Note, however, that the process name will be wlua.exe for every file opened that way.
Of course, it's meant only to be used when the application isn't responding. Your GUI application should provide a way to close it, such as close button, listening for ESC key etc.

Is it possible to let capybara/webdriver start firefox minimized/unfocused?

Is it possible to stop Firefox from popping up when cucumber hits a #javascript tag? After a while it gets frustrating to always get disrupted while running tests.
It would be nice if webdriver was to start Firefox minimized or not focus on it.
There's no API in WebDriver to do this, and it's not really advisable since Firefox won't trigger certain events (like focus, blur) when the window is in the background. I usually work around this by using a virtual machine (e.g. in VirtualBox) or a separate X display.
You can add lines below to Info.plist of Firefox.app. After that it will start without grabbing focus.
<key>LSBackgroundOnly</key>
<string>1</string>

Resources