Force Capybara to fail on unexpected modals - modal-dialog

I'm some tests to trigger and validate a JS alert like this:
it 'triggers a modal' do
accept_alert('Hello world') do
visit '/'
click_button 'Button'
end
end
Which is failing on:
Capybara::ModalNotFound:
Unable to find modal dialog with Hello world
When running headlessly, I thought that the dialog wasn't triggered at all and it was an issue with my JS code but I noticed the test log listed:
* Listening on tcp://127.0.0.1:3001
Modal window has been opened, but you didn't wrap your code into (`accept_prompt` | `dismiss_prompt` | `accept_confirm` | `dismiss_confirm` | `accept_alert`), accepting by default
F
Running in full Chrome I noticed that the modal is being triggered and with the expected message. So now I'm not sure:
why my accept_alert isn't failing the test if the message is actually wrong (e.g. there are hidden characters included and the message is actually Hello world\t. or something)
how is an unwrapped modal since my accept block wraps the whole test body?
I might have a silly syntax error, but I think the above is right & is working on another test. To try and get to the bottom of it, I wanted to disable Capybara's "accepting by default".
Is there any way to:
Make any unexpected modal fail the test (instead of accept/dismiss)?
Log out the text of modals as they occur?

The accepting by default isn't being done by Capybara it's being done be the driver you're using (Cuprite I'm assuming based on the message being produced). If you wrap the action that causes the modal to appear (based on behavior exhibited I'm assuming the visit) rather than the whole test then it will raise an error if the error message isn't correct
since the accept_alert method is only expecting the modal once the block has finished expecting
accept_alert('Hello world') do
visit '/'
end
click_button 'Button'
The behavior of auto-accepting (with warning) unexpected alerts is due to its original design being based on the Poltergeist and I don't believe is configurable currently.

Related

How to Troubleshoot Dexie bound on IDBKeyRange Error

I'm using Dexie.js version 3.0.3-rc.3 in a Vue JS project and I occasionally run into this exception in Chrome (86):
Failed to execute 'bound' on 'IDBKeyRange': The parameter is not a valid key.↵ DataError: Failed to execute 'bound' on 'IDBKeyRange': The parameter is not a valid key.
Here's a screenshot of the full error:
I'm fairly certain the problem lies with something in my data being undefined, but I'm trying to find a good way to troubleshoot this. I paused the Chrome dev tools on exceptions and inspected the code around this particular part of Dexie, but it doesn't reveal what data was used to make this exception occur.
Does anyone have any suggestions on how to find out what's actually wrong? It feels a bit like a needle in a haystack.
== Update ==
Below is the full call stack:
Try inspecting the call stack. I know it can be long until you reach a frame within your application code, but the failing call should be there!

provideDebugConfigurations not getting called

I am using the vscode-mock-debug git as the basis for my work.
Activation event is OnDebug, although same result
I implement provideDebugConfigurations in my DebugConfigurationProvider and its not getting called.
provideDebugConfigurations(folder: WorkspaceFolder | undefined, token?: CancellationToken): DebugConfiguration[] {
return [...my data in here];
}
the resolveDebugConfiguration (the original from mock-debug) is called, I can set a breakpoint. However the provideDebugConfigurations is never getting reached. build 1.36 of vsce. am I missing something obvious ?
this is the answer from the vscode team: https://github.com/microsoft/vscode/issues/78362
I have investigated this and it is expected behavior.
Namely, provideDebugConfigurations is only called then the debug configurations are needed to generate a launch.jsonfile. If you click on the configure command the provideDebugConfigurations will get nicely called.
However if you do not have a launch.json and you simply press Debug Start, vscode will try to start debugging without using debug configurations, but using one on the fly provided by the resolveDebugConfiguration call.
More about this can be found in our docs https://code.visualstudio.com/api/extension-guides/debugger-extension
Thus closing this as designed.

Connecting FluidEnter/FluidExit at run-time

I am toying with the FluidEnter/FluidExit. So in a simple form, here is what I am trying to do:
I created in Main an empty population of agent called Terminal. For now, in Terminal, there is only a fluidEnter connected to a fluidExit (very simple)
enter image description here
Now, on startup, I want to fill this population and set up the proper connections (the terminals are ordered).
So, on startup, I call a function init(), whose body start with Terminal t = add_terminals(); (I have only one terminal for now, just toying with things)
In Main, obviously, I also have a fluidEnter and a fluidExit. I would like to connect the fluidExit of Main to the fluidEnter of the terminal t, and the fluidExit of the terminal t to the fluidEnter of Main, so code (still in init()) looks like
fluidExit.set_fluidEnter(t.fluidEnter);
t.fluidExit.set_fluidEnter(fluidEnter);
I get an exception so obviously, I am doing something wrong. Any idea?
I think the set_fluidEnter function is deprecated or just non-functional.
Instead, you should do:
fluidExit.connect(t.fluidEnter);
So just replace set_fluidEnter with connect... nothing else.
That should do the trick
I was going down the same path as you a couple of months ago. Yes... .connect() works great. It even works as a gate. If it is disconnected, then fluid stops at the exit. Once connected, fluid starts to flow again. It is very slick.

GWT Error Popup

The error popup with the following error message comes on the screen repeatedly when application is in idle state (no user activity is performed).
Error occurred on client: (TypeError): Unable to get property 'iterator_0' of undefined or null reference.
number: -2146823281
at handleEvent_206....EF34544...cache.html
at dispatchEvent_0..EF34544...cache.html
at sucess_184 ..
..
Can anyone give some pointers to navigate to the problamatic area in the code?
The fact that you're getting it repeatedly is probably due to the fact that you're performing an action on a timer (i.e. perform repeatedly an action).
From the small snippet you've shown, I don't think there's anything we can deduce. Do you have a larger stacktrace? It is still possible the error is in your own code (trying to invoke iterator() on a null object).

GWTP Invalid attempt to reveal errorplace, but then works normally

I have a couple of places set up, and they work correctly, except with a delay caused by this issue. They're using nested presenters.
For one place, it appears that any repeat attempt to load it causes an infinite loop of reveal error / unauthorized place (no idea why, no gatekeeper set), but then loads the page correctly. The issue I have with it is the delay and unnecessary log spam it causes - it loads the page correctly, why can't it do it without going through the loop first? Anyone have any ideas?
-- UPDATE --
I am using GWTP 1.4 with GWT 2.7.0, but the project was first created using GWTP 0.6 or maybe earlier. We've updated deprecation etc as we've upgraded, but I know there are anachronisms left.
I tried switching out our ClientPlaceManager with the default, bound the ErrorPlace and UnauthorizedPlace to our home page, and removed its gatekeeper, but it still tries to go to the error place (overrode the revealErrorPlace method and noticed it's throwing the error for a valid token that had been loaded at least once already that session. One page in particular, none of the presenter lifecycle phases are firing, though the presenter is visible (only breaking in firefox I think). I really don't understand it.
-- UPDATE 2 --
I've removed gatekeepers (even specifying #NoGatekeeper), have ensured that the error / unauthorized place have #NoGatekeeper and exists, and overrode revealPlace(request, updateUrl) to output results, and added a try/catch - and it does the exact same thing. An infinite loop, but everything is accessible. my debug output even shows it attempting to reveal the error place, but it never does, just errors out.
This is frustrating to no end.
Stacktrace:
SEVERE: Exception caught: Encountered repeated errors resulting in an infinite
loop. Make sure all users have access to the pages revealed by revealErrorPlace
and revealUnauthorizedPlace. (Note that the default implementations call
revealDefaultPlace)
com.google.gwt.event.shared.UmbrellaException: Exception caught:
Encountered repeated errors resulting in an infinite loop. Make sure all users
have access to the pages revealed by revealErrorPlace and
revealUnauthorizedPlace. (Note that the default implementations call
revealDefaultPlace)
at Unknown.fillInStackTrace_0_g$(student-0.js#36:10580)
at Unknown.Throwable_3_g$(student-0.js#8:10535)
at Unknown.Exception_3_g$(student-0.js#18:10678)
at Unknown.RuntimeException_3_g$(student-0.js#18:61481)
at Unknown.UmbrellaException_3_g$(student-0.js#25:133542)
at Unknown.UmbrellaException_5_g$(student-0.js#26:133603)
at Unknown.fireEvent_7_g$(student-0.js#13:133134)
at Unknown.fireEvent_12_g$(student-0.js#22:154354)
at Unknown.fire_8_g$(student-0.js#17:132936)
at Unknown.fireValueChangedEvent_0_g$(student-0.js#3:154358)
at Unknown.onHashChanged_0_g$(student-0.js#29:154297)
at Unknown.apply_0_g$(student-0.js#28:109006)
at Unknown.entry0_0_g$(student-0.js#16:109062)
at Unknown.anonymous(student-0.js#14:109042)
Caused by: java.lang.RuntimeException: Encountered repeated errors resulting in
an infinite loop. Make sure all users have access to the pages revealed by
revealErrorPlace and revealUnauthorizedPlace. (Note that the default
implementations call revealDefaultPlace)
at Unknown.fillInStackTrace_0_g$(student-0.js#36:10580)
at Unknown.Throwable_2_g$(student-0.js#8:10526)
at Unknown.Exception_2_g$(student-0.js#18:10672)
at Unknown.RuntimeException_2_g$(student-0.js#18:61475)
at Unknown.startError_0_g$(student-0.js#11:92009)
at Unknown.error_2_g$(student-0.js#8:91772)
at Unknown.doRevealPlace_0_g$(student-0.js#10:91762)
at Unknown.revealPlace_1_g$(student-0.js#8:91921)
at Unknown.revealPlace_0_g$(student-0.js#8:91908)
at Unknown.revealErrorPlace_1_g$(student-0.js#8:92109)
at Unknown.error_2_g$(student-0.js#8:91773)
at Unknown.doRevealPlace_0_g$(student-0.js#10:91762)
at Unknown.handleTokenChange_0_g$(student-0.js#12:91848)
at Unknown.onValueChange_4_g$(student-0.js#8:91888)
at Unknown.dispatch_87_g$(student-0.js#16:132968)
at Unknown.dispatch_88_g$(student-0.js#8:132972)
at Unknown.dispatch_0_g$(student-0.js#8:49973)
at Unknown.dispatchEvent_2_g$(student-0.js#14:133006)
at Unknown.doFire_0_g$(student-0.js#9:133250)
at Unknown.fireEvent_8_g$(student-0.js#8:133323)
at Unknown.fireEvent_7_g$(student-0.js#25:133128)
at Unknown.fireEvent_12_g$(student-0.js#22:154354)
at Unknown.fire_8_g$(student-0.js#17:132936)
at Unknown.fireValueChangedEvent_0_g$(student-0.js#3:154358)
at Unknown.onHashChanged_0_g$(student-0.js#29:154297)
at Unknown.apply_0_g$(student-0.js#28:109006)
at Unknown.entry0_0_g$(student-0.js#16:109062)
at Unknown.anonymous(student-0.js#14:109042)
If you're using the DefaultPlaceManager, make sure you have bound DefaultPlace, ErrorPlace and UnauthorizedPlace to Presenter name tokens in your Gin module.
From DefaultPlaceManager's javadoc (http://arcbees.github.io/GWTP/javadoc/apidocs/com/gwtplatform/mvp/client/proxy/DefaultPlaceManager.html):
Important! If you use this class, don't forget to bind DefaultPlace,
ErrorPlace and UnauthorizedPlace to Presenter name tokens in your Gin
module.
Note: The default, error and unauthorized places are revealed without
updating the browser's URL (hence the false value passed in
revealPlace). This will avoid stepping into an infinite navigation
loop if the user navigates back (using the browser's back button).
Here's an example of infinite navigation loop that we want to avoid:
An unauthenticated hits #admin (a place reserved to authenticated
admins) The #unauthorized place is revealed, and the browser's URL is
updated to #unauthorized The user clicks the back button in his
browser, lands in #admin, then #unauthorized, then #admin, and so on.
Also, from https://github.com/ArcBees/GWTP/issues/296:
Verify that the Interface of the Proxy in your Presenter inherit from
ProxyPlace.