How to close the popup window which appears during file downloads - cefsharp

In my implementation of the IDownloadHandler interface i have the following in OnDownloadUpdated. The window stays open??
If downloadItem.IsComplete Or downloadItem.IsCancelled Then
browser.CloseBrowser(True)
browser.Dispose()
End If
Must I have this popup window when a download is happening? I have read here I do, if yes how do I close it. I really thought I read in the project issues/comments that the default was now to automatically close it.

Following the comment of amaitland (Thank you) I have my new window closing properly.
For the VB people - here is what I have added to the OnDownloadUpdated event
If downloadItem.IsInProgress = False And browser.IsPopup And browser.HasDocument = False Then
browser.GetHost.CloseBrowser(False)
browser.GetHost.Dispose()
End If

Related

Client doesn't have a name/class at startup

I'm trying to start an application (Spotify) on a particular tag. Rules aren't applied and now I'm inspecting the client class by printing the class in a notification in the "manage" signal. This results in an empty notification.
client.connect_signal("manage", function (c, startup)
naughty.notify({title=c.class})
end)
When I restart awesome, it does print the client class, so why isn't it working when the client is initially started?
Using xprop, it also prints the class:
WM_CLASS(STRING) = "spotify", "Spotify"
Sounds like a bug in Spotify (and I think I heard about this one before). I would guess that Spotify does not follow ICCCM and only sets its WM_CLASS property after it made its window visible and not before.
I fear that you cannot do much about this except for complaining to Spotify devs to fix their stuff.
You could work around this by starting a timer in the manage signal that checks if a window turns out to be spotify a short time later. Alternatively, you could do something like client.connect_signal("property::class", function(c) if c.class == "Spotify" then print("This is now a spotify window") end end) to react to change to a window's class (of course you'd want to do something more useful to Spotify's windows than printing them).
(Per the ICCCM, a window is not allowed to change its class while it is visible, but who cares about standards...)
I had a similar issue with the claws-mail client. Inspecting it via xprop, it shows
WM_CLASS(STRING) = "claws-mail", "Claws-mail"
but awesome just did’t apply the rules for it. The trick was giving awesome-wm both of these class names in the rules section by providing a set of characters to chose from:
rule = {class = "[Cc]laws%-mail"}
I hope this works for your spotify application, too.
For further reading about patterns in lua I suggest this:
https://www.lua.org/pil/20.2.html

Send future clients to right monitor in awesome?

I'm trying to implement a very customized implementation of awesome.
I have two monitors. I'd like to have my first client always open on the left monitor (a Chrome window in kiosk mode), then all clients after open up on the right monitor.
Are there any custom layouts that accomodate this?
I'd be willing to program it myself, but I'm not sure how to bind a script to some kind of "new client" event.
The new client event is the manage event. It is emitted whenever, well, a new client gets managed by awesome.
To send the first client that ever appears to screen 1 and all following ones to screen 2, you could do something like this:
local first = true
client.connect_signal("manage", function(c)
if first then
c.screen = 1
else
c.screen = 2
end
first = false
end)

Receiving integral sign when using confirm dialog in atom-editor

For some reason, when I use the following code in package I'm trying to contribute to, an integral sign (∫) appears in the active document when a button is selected on the dialog.
checkAutoSave: ()->
if atom.workspace.getActiveTextEditor().isModified()
if atom.config.get('build.saveOnBuild') is true
atom.workspace.getActiveTextEditor().save()
return 1
else if atom.config.get('build.promptToSaveOnBuild') is true
diaDirection = atom.confirm
message: 'Do you want to save the current file before building?'
detailedMessage: 'This message can be turned off in the Build settings.'
buttons: ['Yes', 'No', 'Cancel Build']
switch diaDirection
when 0
atom.workspace.getActiveTextEditor().save()
return 1
when 1
return 0
when 2
return -1
else #Current File wasn't changed.
return 0
I have tried narrowing it down and I am 100% it has something to do with the dialog. The problem does not exists without the dialog call. The Integral sign appears in the document regardless of the button pressed.
I've had a similar problem a while ago - see here for more details.
The action I wanted to trigger in the editor was bound to Ctrl+Alt+B, which by default inserts the integral sign on Mac OS X. The integral sign was inserted into the currently open document when I opened a standard alert box from my package's code.
I didn't found out why, but it looks similar to your problem. In the end, I resolved it by removing the alert and using an Atom view instead for showing the message. As soon as I did this, the integral sign was no longer inserted into the document.
It looks like there's an issue with the key binding and preventing event propagation when using some dialogs. In some cases, the key event is handed to the OS and it inserts the character associated with the pressed key.
Maybe you can try using an Atom view instead of the confirm dialog, and it will resolve your issue as well.

How to test a confirm dialog with Cucumber?

I am using Ruby on Rails with Cucumber and Capybara.
How would I go about testing a simple confirm command ("Are you sure?")?
Also, where could I find further documentation on this issue?
The selenium driver now supports this
From Capybara you would access it like this:
page.driver.browser.switch_to.alert.accept
or
page.driver.browser.switch_to.alert.dismiss
or
page.driver.browser.switch_to.alert.text
Seems like there's no way to do it in Capybara, unfortunately. But if you're running your tests with the Selenium driver (and probably other drivers that support JavaScript), you can hack it. Just before performing the action that would bring up the confirm dialog, override the confirm method to always return true. That way the dialog will never be displayed, and your tests can continue as if the user had pressed the OK button. If you want to simulate the reverse, simply change it to return false.
page.evaluate_script('window.confirm = function() { return true; }')
page.click('Remove')
I've implemented these two web steps in /features/step_definitions/web_steps.rb:
When /^I confirm popup$/ do
page.driver.browser.switch_to.alert.accept
end
When /^I dismiss popup$/ do
page.driver.browser.switch_to.alert.dismiss
end
If you want to specifically test the message being displayed, here's a particularly hacky way to do so. I don't endorse it as beautiful code, but it gets the job done. You'll need to load http://plugins.jquery.com/node/1386/release, or change it to do cookies natively if you don't want jQuery.
Use this sort of story:
Given I am on the menu page for the current booking
And a confirmation box saying "The menu is £3.50 over budget. Click Ok to confirm anyway, or Cancel if you want to make changes." should pop up
And I want to click "Ok"
When I press "Confirm menu"
Then the confirmation box should have been displayed
And these steps
Given /^a confirmation box saying "([^"]*)" should pop up$/ do |message|
#expected_message = message
end
Given /^I want to click "([^"]*)"$/ do |option|
retval = (option == "Ok") ? "true" : "false"
page.evaluate_script("window.confirm = function (msg) {
$.cookie('confirm_message', msg)
return #{retval}
}")
end
Then /^the confirmation box should have been displayed$/ do
page.evaluate_script("$.cookie('confirm_message')").should_not be_nil
page.evaluate_script("$.cookie('confirm_message')").should eq(#expected_message)
page.evaluate_script("$.cookie('confirm_message', null)")
end
Updating this for current releases of Capybara. Most Capybara drivers today support the modal API. To accept a confirm modal you would do
accept_confirm do # dismiss_confirm if not accepting
click_link 'delete' # whatever action triggers the modal to appear
end
This can be used in Cucumber with something like
When /^(?:|I )press "([^"]*)" and confirm "([^"]*)"$/ do |button, msg|
accept_confirm msg do
click_button(button)
end
end
which will click the named button and then accept a confirm box with text matching msg
The capybara-webkit driver supports this as well.
Scenario: Illustrate an example has dialog confirm with text
#
When I confirm the browser dialog with tile "Are you sure?"
#
=====================================================================
my step definition here:
And(/^I confirm the browser dialog with title "([^"]*)"$/) do |title|
if page.driver.class == Capybara::Selenium::Driver
page.driver.browser.switch_to.alert.text.should eq(title)
page.driver.browser.switch_to.alert.accept
elsif page.driver.class == Capybara::Webkit::Driver
sleep 1 # prevent test from failing by waiting for popup
page.driver.browser.confirm_messages.should eq(title)
page.driver.browser.accept_js_confirms
else
raise "Unsupported driver"
end
end
Prickle adds some handy convenience methods for working with popups in selenium and webkit
This gist has steps to test a JS confirm dialog in Rails 2 and 3 with any Capybara driver.
It's an adaptation of a previous answer, but doesn't need the jQuery Cookie plugin.
Tried the above answers with no luck. In the end this worked for me:
#browser.alert.ok

ASP.Net links won't disable if done during postback

I'm still fairly new to ASP.Net, so forgive me if this is a stupid question.
On page load I'm displaying a progress meter after which I do a post back in order to handle the actual loading of the page. During the post back, based on certain criteria I'm disabling certain links on the page. However, the links won't disable. I noticed that if I force the links to disable the first time in (through debug) that the links disable just fine. However, I don't have the data I need at that time in order to make the decision to disable.
Code Behind
If (Not IsCallback) Then
pnlLoading.Visible = True
pnlQuote1.Visible = False
Else
pnlLoading.Visible = False
pnlQuote1.Visible = True
<Load data from DB and web service>
<Build page>
If (<Some Criteria>) Then
somelink.Disable = True
End If
End If
JavaScript
if (document.getElementById('pnlQuote1') === null) {
ob_post.post(null, 'PerformRating', ratingResult);
}
ob_post.post is an obout js function that does a normal postback and then follows up with a call to the server method named by the second param. then followed by the call to a JavaScript method named by the third param. The first parameter is the page to post back to. A value of null posts back to the current page.
The post back is working fine. All methods are called in the correct order. The code that gives me trouble is under the code behind in bold. (somelink.disabled = True does not actually disable the link) Again, if I debug and force the disabling of the link to happen the first time in, it disables. Does anyone know what I might do to get around this?
Thanks,
GRB
Your code example is using the IsCallBack check, while the question text talks about the IsPostback Check. I'd verify that you're using Page.IsPostBack in your code to turn off the links.

Resources