Windows 10
Microsoft Edge Version 40.15063.674.0 (15.15063)
An XPath that works fine in Chrome and Firefox is failing in Microsoft Edge.
var filterRow2 = Driver.FindElements(By.XPath("//table//tr[contains(#class,'table-filter')]"));
this find the element when run in Chrome and Firefox but not in Edge. I found posts in the microsoft developer forum discussing the same issue but didn't see anything stating the issue was ever resolved.
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/4696709/
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8516233/
More Information:
Example code which fails in version 15063
I test your 1 line of code with Edge web driver and chrome web driver. (Tested with Edge 44)
static void Main(string[] args)
{
// IWebDriver driver = new EdgeDriver();
IWebDriver driver = new ChromeDriver();
driver.Navigate().GoToUrl("https://stackoverflow.com/");
String xpath = "//body[contains(#class, 'home-page new-topbar')]";
var filterRow2 = driver.FindElements(By.XPath("//table//tr[contains(#class,'table-filter')]"));
Console.WriteLine(filterRow2.ToString());
driver.Close();
}
Below is the result from Chrome Web driver.
Below is the result from Edge Web driver.
I suggest you to use the latest updates for MS Edge browser and use latest web driver for Edge may help to fix the issue.
Reference:
Microsoft Edge (Incorrect XPath behavior for partial #class matches)
Let us know, if I misunderstand anything from your above description. I will try to correct myself.
Related
My app uses Xamarin.Forms.Maps to display a map and also for geocoding. The map is displayed on a separate page when the user navigates to it from the main page. I use the geocoder to reverse geocode the current location so that I have the address. This is done from various places other than the map page.
When I run the app on a device (even in debug mode) the geocoder works right away in iOS and Android, but does not work in UWP. After I navigate to the map page and display the map, then go back to a different page to use the geocoder it starts working.
I saw a thread about the map not working with release build so I added the following code:
var laRendererAssemblies = new[] { typeof(Xamarin.Forms.Maps.UWP.MapRenderer).GetTypeInfo().Assembly };
Xamarin.Forms.Forms.Init(e, laRendererAssemblies);
//Xamarin.Forms.Forms.Init(e);
Xamarin.FormsMaps.Init("MyBingMapsKey");
This has not helped the issue with the Xamarin.Forms.Maps.Geocoder. I also tried creating an instance of Xamarin.Forms.Maps.Map in my main page, but that did not help either. Is there a way to prime the map component so that the Geocoder will work on a device? (My test device is ARM, but it happens when I run on Local
Machine (Win 10) too)
Following is a snippet of the call to the Geocoder (which works fine once the user has navigated to the Map page and back - and it works fine in iOS and Android - and as such I don't believe it is a problem with the code, but here it is):
public static async Task<Plugin.Geolocator.Abstractions.Position> Geocode(string address)
{
try
{
var loGeocoder = new Xamarin.Forms.Maps.Geocoder();
System.Diagnostics.Debug.WriteLine("Get Lat/Lon");
var lcolPositions = await loGeocoder.GetPositionsForAddressAsync(address);
if (lcolPositions != null)
After doing some research and ensuring that your geodecode class being static wouldn't mess with the async/await pattern in the UWP build. I've come across a few references to this particular problem with the built in Forms.Map geodecoder elsewhere, not just for UWP it has also been noted for android‡.
I took some time to have a look at one of our current cross-platform applications that we have in the app stores, and according to our internal documentation we switched out both the xamarin.forms map, and the geodecoder for custom ones.
The plugin that we use for our cross-platform application is the 'GelocatorPlugin' created by james montemagno, and can be found here.
It can be added to your project as a Nuget package if you prefer, and the implementation of it is very similar to the default one, so there's very little code to change. The primary benefit is that the UWP element of the geodecode plugin has been modified to take into account windows advanced tracking scenarios (details found here).
It should be a lot more stable than the one your using, once installed you simply use it like so:
Reverse Geocoding
Based on a location that is passed in, thi swill grab a list of
addresses.
UWP requires a Bing Map Key, which you can acquire by reading this
piece of documentation.
try
{
var addresses = await locator.GetAddressesForPositionAsync (position, string mapKey = null);
var address = addresses.FirstOrDefault();
if(address == null)
Console.WriteLine ("No address found for position.");
else
Console.WriteLine ("Addresss: {0} {1} {2}", address.Thoroughfare, address.Locality, address.Country);
}
catch(Exception ex)
{
Debug.WriteLine("Unable to get address: " + ex);
}
‡ Links to similar problems - Link 1, Link 2
resolved after added following lines in APP.xaml.cs (UWP project)
Xamarin.FormsMaps.Init("bingmapkey");
Windows.Services.Maps.MapService.ServiceToken = "bingmapkey";
Yesterday I got the update for Android 5.0 on my Nexus 4, and the altbeacon library stopped detecting beacons. It appears that didEnterRegion and didRangeBeaconsInRegion are not even getting called when monitoring and ranging, respectively.
Even the Locate app from Radius Networks behaves differently now, the values from beacons, once they are detected, doesn't get updated anymore and often it appears as if the beacons went out of range.
One thing I noted differently, is that now in the logcat it appears the following line "BluetoothLeScanner﹕ could not find callback wrapper". I went ahead and looked for that class and saw that it was introduced with Android L, but I don't know if that has something to do with it.
It's important to say that before the update I had been working with both the Locate app and the Reference Application without any trouble.
I don't know if this is a generalized problem or not, but if it happened to me I'm sure it could happen to someone else, so any help it would really be appreciated.
Thanks in advance!
UPDATE:
After failing at getting the library to work I decided to try the Android L branch of the library. What I did was that I plugged in the new library into the Reference App, but didn't work as expected either.
The Monitor Activity seems to be working ok by notifying when the device has entered a new region. However, the Ranging Activity doesn't report any beacons, although didRangeBeaconsInRegion is getting called, always report zero beacons. Curiously, when the activity is paused (switching momentarily to another app) the logcat shows that now didRangeBeaconsInRegion does get called with actual beacons.
I'm kind of stuck right now because I don't know how to get any of libraries working on Android L, so again, any help would really be appreciated.
I'm using the latest Altbeacon build on 5.0+ and have no problem with it. in fact, I never used it on kitkat so i'm not really sure i can help but here is my working code which listen to iBeacons.
implement beaconConsumer:
public class MainActivity implements BeaconConsumer
init BeaconManager
beaconManager = BeaconManager.getInstanceForApplication(this);
if (beaconManager != null && !beaconManager.isBound(this)) {
beaconManager.getBeaconParsers().add(new BeaconParser().
setBeaconLayout("m:0-3=4c000215,i:4-19,i:20-21,i:22-23,p:24-24"));
beaconManager.bind(this);
}
onConnect and start listner
#Override
public void onBeaconServiceConnect() {
beaconManager.setRangeNotifier(new RangeNotifier() {
#Override
public void didRangeBeaconsInRegion(Collection<Beacon> beacons, Region region) {
if (beacons.size() > 0) {
Beacon firstBeacon = beacons.iterator().next();
}
}
});
beaconManager.startRangingBeaconsInRegion(new Region("com.example.app", null, null, null));
}
this code is working on 3 devices
Nexus 4 5.0.1
Samsung Galaxy s4 - Stock 5.0.1
Samsung Galaxy s4 - CM12 5.1.1
Old question, but maybe some people will try to find answer for higher systems where you have to ask for permissions. You need to ask for Manifest.permission.ACCESS_FINE_LOCATION before scanning. At least that was the problem I met. In my opinion lib should crash such cases at least and indicate the problem
Our company is migrating our help systems over to HTML5 format under Flare. We've also added Topic based access to the help systems using Flare CSHID's on the URI command line for accessing the topic directly, such as index.html#CSHID=GettingStarted to launch the GettingStarted.html help page.
Our apps are written in C++ and leverage the Win32 ShellExecute() function to spawn the default application associated with HTTP to display the help system. We've noticed that ShellExecute() works fine when no hashtag is specified, such as
ShellExecute(NULL, _T("open"), _T("c:\\Help\\index.html"), NULL, NULL, SW_SHOWNORMAL);
This function will launch the default browser associated with viewing HTML pages and in this case, the File:/// protocol handler will kick in, the browser will launch and you will see file:///c:/Help/index.html in the address bar.
However, once you add the # information for the topic, ShellExecute() fails to open the page
ShellExecute(NULL,_T("open"),_T("c:\\Help\\index.html#cshid=GettingStarted"),NULL,NULL,SW_SHOWNORMAL);
If the browser opens at all, you'll be directed to file:///c:/Help/index.html without the #cshid=GettingStarted topic identification.
Note that this is only a problem if the File protocol handler is engaged through ShellExecute(), if the help system lives out on the web, and the Http or Https protocol handler is engaged, everything works great.
For our customers, some of whom are on a private LAN, we cannot always rely on Internet access, so our help systems must ship with the application.
After some back-and-forth with Microsoft's MSDN team, they reviewed the source code to the ShellExecute() call and it was determined that yes, when processing File:/// based URLs in ShellExecute(), the ShellExecute() call will strip off the # and any data it finds after the # before launching the default browser and sending in the HTML page to open. MS's stance is that they do this deliberately to prevent injections into the function.
The solution was to beef up the ShellExecute() call by searching the URL for a # and if one was found, then we would manually launch the default browser with the URL. Here's the pseudocode
void WebDrive_ShellExecute(LPCTSTR szURL)
{
if ( _tcschr(szURL,_T('#')) )
{
//
//Get Default Browser from Registry, then launch it.
//
::RegGetStr(HKCR,_T("HTTP\\Shell\\Open\\Command"),szBrowser);
::CreateProcess ( NULL, szBrowser + _T(" ") + szURL, NULL, NULL, FALSE, 0, NULL, NULL, &sui, &pi);
}
else
ShellExecute(NULL,_T("open"),szURL,NULL,NULL,SW_SHOWNORMAL);
}
Granted there's a bit more to the c++ code, but this general design worked for us.
I tried WebDrive's solution and it didn't really work on Windows 10.
"HTTP\Shell\Open\Command" default value is set to Internet Explorer path, regardless of what my default browser setting. However, for Internet Explorer that solution DOES work.
Process to fetch default browser path on Windows 10 is a bit different (How to determine the Windows default browser (at the top of the start menu)) but even then the solution is not guaranteed to work, depending on the browser. E.g. for me it didn't work with Edge.
To get it to work with Edge I had to add "file:///" to the URL -- but that also makes the URL work with ShellExecute(). So, at least on Windows 10, all I needed to do was this:
ShellExecute(NULL,_T("open"),_T("file:///c:/Help/Default.html#cshid=1648"),NULL,NULL,NULL);
UPDATE:
The above stopped working months ago. What I eventually did was go through temporary file, as described here: https://forums.madcapsoftware.com/viewtopic.php?f=9&t=28376#p130613
Use FindExecutable() to get the default browser and pass the full help file path with its queries (?) and fragments (#) as the lpParameters parameter to ShellExecute(). They won't get stripped off there.
Then handle the case if it is a Store App (most likely Microsoft Edge).
Pseudo C code:
if (FindExecutable(_T("c:\Help\index.html"), NULL, szBrowser)
{
if (szBrowser == _T("C:\WINDOWS\system32\LaunchWinApp.exe"))
{
// default browser is a Windows Store App
szBrowser = _T("shell:AppsFolder\Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge");
}
}
else
{
szBrowser = szURL;
szURL = NULL;
}
ShellExecute(NULL, NULL, szBrowser, szURL, NULL, SW_SHOWNORMAL);
I solved the problem without using any method other than ShellExecute in a Qt Application
QString currentpath = QDir::currentPath();
QString url = "/help//html/index.html#current";
QString full_url = "file:///" + currentpath + url;
QByteArray full_url_arr= full_url.toLocal8Bit();
LPCSTR lp = LPCSTR(full_url_arr.constData());
ShellExecute(NULL, "open", lp, NULL, NULL, SW_SHOWNORMAL);
I really need some help on this, as I have no idea how to fix it! :/
Got a problem here.
My application is working fine on my computer, both offline and online (flash uploaded to our webservers). It works fine in both IE and Firefox.
However, some user do have problem running it in IE, while Firefox is still ok..
The app itself works, the error comes when trying to buffer some frames to a BitmapData.
So, in Firefox, it works great.
In IE (on my computer) it works great.
In IE (on other computers) it does not work, and this error is cast. It happens right at the end, which means it all works fine until the last time the function is run. (it's run like this to allow updating the progressbar. If I set the for loop to 180 then it all freezes untill completed. Thats why I do 10 and 10.)
Any help regarding this would be great, as I'm completely stuck here...
I've traced the size of the bitmapdata, and at the time of the error it's 1920x1080, which is what it's supposed to be.
This is the code where it fails:
fpsoSWFBuffer = new BitmapData(fpsoMC.width, fpsoMC.height, false, 0x00ff0000);
And this is the whole function where the code is located:
public function bufferFpsoImages(evt:TimerEvent):void{
for (var i:int = 0; i<10; i++){
fpsoMC.gotoAndStop(currentFpsoFrame);
fpsoSWFBuffer = new BitmapData(fpsoMC.width, fpsoMC.height, false, 0x00ff0000);
fpsoSWFBuffer.draw(fpsoMC);
fpsoImgArray[currentFpsoFrame] = fpsoSWFBuffer;
currentFpsoFrame++;
}
if (currentFpsoFrame <= (totImg360-10)){
// Still buffering frames //
myLoadingPanel.setBufferProg(currentFpsoFrame);
var fpsoTimer:Timer = new Timer(1,1);
fpsoTimer.addEventListener(TimerEvent.TIMER_COMPLETE, bufferFpsoImages);
fpsoTimer.start();
}else{
// All frames buffered //
currentFpsoFrame = 0;
fpsoLoaded = true;
fpsoLoading = false;
ncFPSO.removeElement(myLoadingPanel);
myLoadingPanel = null;
var fpsoBitmap:Bitmap = new Bitmap(fpsoImgArray[0]);
fpsoBitmap.smoothing = true;
fpsoImage.source = fpsoBitmap;
}
}
EDIT:
I've added some debugging functions to it now, to be able to know where it fails. (as it works during debugging, I need to debug the realtime version online).
This is what I get:
ErrorID=2015
ErrorMessage=Error #2015
ErrorPos=fpsoSWFBuffer = new BitmapData(1920, 1080, false, 0x00ff0000);
CurrentFpsoFrame=168
Position in For Loop=8
EDIT2: And here is the error message I finally got inside of Flash Builder. So now it's crashing here too.. =/
ArgumentError: Error #2015: Invalid BitmapData.
at flash.display::BitmapData/ctor()
at flash.display::BitmapData()
at Main/bufferTemplateImages()[E:\Workspace - Flash Builder\vCog Workspace\vCog Communicator 3.0\src\Main.mxml:461]
at flash.events::EventDispatcher/dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at flash.utils::Timer/tick()
Your buffering 1.5gb of memory? Flash keeps requesting memory from the OS until the OS can't give anymore. If it works on your computer, but not others, maybe their computers are running a lot of other program requesting memory and can't supply enough memory to your project. The other thing I would check is, what version of the OS they are using 32bit windows only can see a max of 2Gb of memory. Although This is simply a theory. Maybe try and compress the images first to limit memory usage.
It seems like IE have some sort of max memory useage restriction with flash, and Firefox does not.
I might be wrong, but I fixed it by rewriting my code to handle smaller files (less memory useage) and loading in a high-res image after the user have rotated the view.
I used to buffer 1,5GB meory, now I buffer about 750MB and it works.
Still strange that IE has limitations, and Firefox and Chrome does not...
Oh well.. =/
I've created a fileUpload.mxml component in flex 3 which basically uploads m4a's to a designated server. The general code is below:
private var uploadURL:URLRequest;
private var file:FileReference;
file=new FileReference();
file.browse(getTypes());
var params:URLVariables = new URLVariables();
params.fileID = model.selectedFileUpload.fileUploadId.toString();
uploadURL.data = params;
uploadURL.url= model.mainDir + "/php/upload.php";
file.upload(uploadURL);
Everything works fine on a windows pc, but not on a mac pc. It stops at file.upload(uploadURL) (and thus doesn't trigger Event.COMPLETE).
Has anyone experienced this problem on the mac os x? And if so, how did you overcome it?
Any advice would be appreciate.
Regards,
Angus
The COMPLETE event is not triggered in Mac due to a bug UNLESS the server send ANY output back to the server.
A simple echo of any string would do.
this issue is detailed in the SWFUpload boards along this very solution (there may be other causes, also discussed in that thread, but the not output is the most common one): http://swfupload.org/forum/generaldiscussion/872