I'm writing some code to test IOS app using X-code and instrument. I want to check the state of a button when it toggle on/off. I try using method .isEnabled() to check if it's on/off but it fails to determine the state. In other words, instruments always passes the line "if (mainWindow.popover().buttons()[17].isEnabled())" regardless tapping the button or not.
here's part of my code:
//Button is OFF as default
//Tap to turn it ON
mainWindow.popover().buttons()[17].tap();
//Have a short delay to ensure it changes state
target.deday(1);
//Check to see if it's ON
if (mainWindow.popover().buttons()[17].isEnabled()) {
UIALogger.logMessage("button ON");
}
...
The root cause of this issue is that the button does not return any value when it toggles ON/OFF. It should return value 0 if it's Off and 1 if it's ON. I'm working out this issue with dev team.
BTW, I also mis-understood the function .IsEnabled() as it only checks if a button is able to tap or not. The function returns false if a button is greyed out (could not be tap). Otherwise, it should return true :)
Related
Electron 7.1.10, Windows 10
When my app enters full screen, I'm trying to turn off menu visibility and make it "autohide" so it can be accessed through the Alt-key. The code below does turn it off but does not enable the "reveal through Alt-key" behavior.
I've tried commenting out the mainindow.setMenuBarVisibility(); calls since maybe that is absolute: menu never to be shown, but then the menu still displays in full screen. I've also tried changing the order, so that I call mainindow.autohideMenuBar = true before setting visibility to false. No luck.
Has anyone else encountered this?
The BrowserWindow docs seem to indicate that what I am trying to do should work:
win.setMenuBarVisibility(visible) Windows Linux
visible Boolean
Sets whether the menu bar should be visible. If the menu bar is
auto-hide, users can still bring up the menu bar by pressing the
single Alt key.
if (mainindow.isFullScreen()) {
// coming out of full screen
mainindow.setMenuBarVisibility(true);
mainindow.autohideMenuBar = false
mainindow.setFullScreen(false);
} else {
// entering full screen
mainindow.setMenuBarVisibility(false);
mainindow.autohideMenuBar = true
mainindow.setFullScreen(true);
}
So setting the property does not work but using the older method setAutoHideMenuBar does – though the docs state that that is deprecated. Seems like a bug.
The Electron team is currently undergoing an initiative to convert
separate getter and setter functions in Electron to bespoke properties
with get and set functionality. During this transition period, both
the new properties and old getters and setters of these functions will
work correctly and be documented.
win.setAutoHideMenuBar(hide)
hide Boolean
Sets whether the window menu bar should hide itself automatically.
Once set the menu bar will only show when users press the single Alt
key.
If the menu bar is already visible, calling setAutoHideMenuBar(true)
won't hide it immediately.
Deprecated
if (mainWindow.isFullScreen()) {
// coming out of FS
// mainWindow.autohideMenuBar = false
mainWindow.setAutoHideMenuBar(false);
mainWindow.setMenuBarVisibility(true);
mainWindow.setFullScreen(false);
} else {
// mainWindow.autohideMenuBar = true
mainWindow.setAutoHideMenuBar(true);
mainWindow.setMenuBarVisibility(false);
mainWindow.setFullScreen(true);
}
I am working with a big application, in that most of the pages are already build and the current architecture use location.href for changing the url. We are using angularJS and I know it is not the right way to do routing in angularJS but changing everywhere will be a headache.
The issue is I have a requirement that to show a dynamic breadcrumb in each page, and it should show the correct breadcrumb path when a user click on browser back button. I have created a history array for the same and when ever a browser back button click event happens I will remove one item from array and push last item to breadcrumb. Everything works fine with links as url, but logic fails when the redirection is happens inside a function like below
location.href="#/dashboard";
This below code is treated as a browser back button click by code. Below is my back button detecting code .
$rootScope.$on('$locationChangeSuccess', function() {
$rootScope.actualLocation = $location.path();
});
$rootScope.$watch(function () {return $location.path()}, function (newLocation, oldLocation) {
if($rootScope.actualLocation === newLocation) {
//logic
}
else{
//logic
}
});
I can use a rootScope variable for condition check before each redirection code , but it is not a proper solution because the redirection code is there in more than 500 places in the application.
So is there anyway to detect whether the call is coming from a browser back button or from some location.href ??
I have the following code, which works 100% ok on Chrome and Safari, but on IE 10 sometimes works and sometimes don't.
Sys.Focus = function(obj){
if(Sys.Anim.length>0){
Sys.Fp = obj;
return;
}
obj.focus();
}
.
.
.
function Animate(...){
var i,...
.
.
.
if(Finished(Sys.Anim[i])){
Sys.Anim.splice(i,1);
if(Sys.Anim.length==0){
if(Sys.Fp){
Sys.Focus(Sys.Fp)
Sys.Fp = null;
}
}
}
.
.
.
}
.
.
.
email = document.getElementById("email");
Sys.Focus(email);
email.onkeydown = function(){
debugger
.
.
.
}
In response to different user actions, some objects on screen either change color or move around, this is done by Animate(), objects to be animated are added to an Array (Sys.Anim) and removed when the animation ends. In order to keep everything smooth, if the page becomes ready for input before the animation ends (which almost always happens), the focus() call is delayed until the animation ends, that is about 1/3 of a second.
Everything works just as expected in all browsers except IE 10. At first I thought there was a logic error on my code, however I debugged it with the Developer Tools and I discovered all the steps are carried on correctly, the problem is that focus() is not actually working all the times.
Another important detail... when focus() succeeds email.onkeydown is executed every time I hit a key, however when focus() fails I obviously must click on the input control to focus it manually, but when this happens the email.onkeydown function is never called even when the content of the input control is updated with every key punch.
I tryed:
setTimeout(function(){obj.focus()},100);
which was proposed as a solution for this problem, but it doesn't solve mine.
Why this happens and how can be worked around?
UPDATE:
For testing proposes I added the following function:
email.onfocus = function(){
debugger
}
which brings the debugger only when focus() succeeds, if focus() fails the debugger won't pop up even if you focus the input control manually with a mouse click, because in this case I simply cannot focus the input control by using the Tab or Shift-Tab keys... is just as if it didn't exist!!!
Solved!!!
After lots of frustrating tests I discovered that the input control was nested inside a DIV which in some circumstances was disabled, dumb of me to disable a DIV.
...However all other browsers only actually disable the input control if it is explicitly disabled. The guys at Microsoft always trying to be "too clever" decided to take a conterintuitive approach and leave it half done.
The problem and my complaint is that the input control does not look disabled, it looks normal and the caret actually appears if you click on it, you can even type on it no matter how disabled it was supposed to be... so for the record, always remember IE 10 only half disables input controls which are inside disabled DIV giving you no visual clue of what's going on.
I have a phonegap project on iPhone and Android. The issue appears to be a race condition on the surface, but I don't understand how it happens. Users are able to click on a button which has a closure callback that sets a property of an object, and then clears the screen and loads the main menu. In code:
button.onclick = function (employee) {
return function () {
employee.task = "some task";
returnToMenu();
}
}(employees[i]);
After the user is back on the main menu, they can click on a button that loads a screen which displays all the users. If an employee has that task property set, additionally formatting should be done to the button for that employee.
if (employee.task)
// style the button being created for this employee
Somehow, if one clicks fast enough, the formatting is not done. If you click back (to the main menu), and reload the screen, the formatting is now done. Given the code above, I do not see how employee.task could possibly return undefined after the menu has been loaded. What's going on here?
I try to understand Firefox's behavior regarding the added "prevent this page from creating additional dialogs" on dialog boxes.
Using jquery, if I add the following listeners :
//html
<input class="testInput" />
//javascript
$('.testInput')
.click(function(){ alert('clicked') })
.keyup(function(){ alert('keyup') })
When clicking on the input, the alert box appears normally, until the
~13th time.
When hitting a key, on the other hand, the second message box already
appears with the message "prevent this page from creating additional
dialogs". Actually, there seems to be some tiemout, and if I wait
like 2 seconds between two keystrokes, the message disappears.
From my informal tests, 2. actually applies whenever the alert box is not called from within a onclick callback (e.g : keyup callback, displaying an alert box in answer to an ajax action...)
I am using Firefox 9.0.1 under Ubuntu, as far as I know I haven't tweaked firefox's settings regarding these thresholds.
I imagine it happens with any recent version of any browser.
I am using the jQuery library, but I don't think it is relevant here.
My question is :
What are the exact rules which make this warning appear in a dialog box ?
[Edit]
Using Chromium/Ubuntu (version 17.0.963.26), the threshold seems to be only the delay between two dialog boxes.
You can test this from jsfiddle here (thx Rory McCrossan)
The exact rule(s): A timed interval between the dialog boxes popping up.
The value used to determine this is set in SUCCESSIVE_DIALOG_TIME_LIMIT
Check out line 2614 in the link below the snippet:
nsGlobalWindow::DialogOpenAttempted()
TimeDuration dialogDuration(TimeStamp::Now() - topWindow->mLastDialogQuitTime);
if (dialogDuration.ToSeconds() < Preferences::GetInt("dom.successive_dialog_time_limit",SUCCESSIVE_DIALOG_TIME_LIMIT)){topWindow->mDialogAbuseCount++;return (topWindow->GetPopupControlState() > openAllowed || topWindow->mDialogAbuseCount > MAX_DIALOG_COUNT);}topWindow->mDialogAbuseCount = 0; return false;}
Link to source
You can kick around the Firefox source if you like. Note that different browsers will have different rules.
The relevant code for Firefox is in nsGlobalWindow.cpp and nsGlobalWindow.h (the links below are to line numbers, and so will slowly rot as the source changes). It appears to be controlled by the constants MAX_DIALOG_COUNT (10) in nsGlobalWindow.h and SUCCESSIVE_DIALOG_TIME_LIMIT (3, units are seconds). nsGlobalWindow.cpp keeps a count (mDialogAbuseCount). Apparently, the dialogDuration function either increments or clears mDialogAbuseCount depending on whether the dialog has been open longer than the SUCCESSIVE_DIALOG_TIME_LIMIT. The AreDialogsBlocked function uses the mDialogAbuseCount (in part) to decide whether they're blocked.
So in short: If you're repeatedly opening pop-ups and then closing them within three seconds, after 10 or so you'll trigger something.