I need to examine the HTML of a popup, which works by injecting new HTML into the document. However, if you off-click the popup it automatically closes. Chrome's Developer Tools requires you to change focus to that window, which causes an off-click.
I have figured out a workaround that helps but is ultimately insufficient. You can right-click on the injected HTML in DevTool's Elements tab, which allows you to copy the injected HTML before the browser recognizes the off-click. This helps, but doesn't allow you to fully examine the injected HTML.
(The following solution is insufficent)
Is there a solution that allows me to fully examine the popup's HTML?
Related
I make a multi-device app that has a TWebBrowser component.
If i write this code
WebBrowser1.Navigate('https://google.com');
it opens the form as it should be.
But if i write this code
WebBrowser1.Navigate(edit1.text);
where edit1.text=the URL of a GoogleForms form (=https://docs.google.com/forms/d/e/1FAIpQLScLDCv_LeYJzvMoxnmvt_gN_gqeup7_vbU8VLaC-qXNPEGMIQ/viewform?vc=0&c=0&w=1&fbzx=3551763952707733753), it shows the form confused (the dropdown components as list of text, the "submit" button as text etc) like this :
is there a solution, please ?
PS. the form is opened in Internet Explorer (and Google) right.
The reason why this happens is that by default TWebBrowser component is opening web pages in compatiblity mode. This prevents myn moder web pages to show properly.
So in order to avoid this you need to opt in to the browser emulation feature using the documented registry key.
You can find more info about this on the link bellow
https://stackoverflow.com/a/25843958/3636228
I need to open an url on a new and single tab chrome window, as you would normally do with window.open and "_blank", but when done inside a chrome app, the url is opened in a new tab of an already running chrome, ignoring all the window features options (width, height, etc).
Are we doing something wrong or is this a chrome app constrain? Any way to solve it?
Best regards
Sergio
You have two options.
Use a proper API to open a tab, chrome.browser.openTab, but that doesn't give you an ability to open it in a separate window. Such an option would probably be a nice addition, you can try submitting a feature request for it.
Open an app window with a local HTML file that embeds the required web content inside a <webview>. You then have full control over appearance, but lose access to browser's conveniences like cookie/password store of the current user, and have to implement some things yourself like dialog boxes.
I'm afraid a Chrome app cannot interact with the browser itself in a more detailed way by design.
Problem - As the project was growing from some point on I cannot use anymore Worklight's Rich Page Editor. It looks as on the picture.
Configuration:
Eclipse Juno EE
Worklight 6.0.0.1
Project details - All pages are packed in the same HTML file. At the moment HTML file contains 6-7 pages in about 1100 lines. Compiling and all the rest works.
There should be no problems at all with that page size or number of views, so the appearance is likely tied to recent changes in the application logic itself. In your screenshot the editor has already finished loading the page into the embedded browser (otherwise you would still see a "Loading..." message in the editor's toolbar). The circular icon in the middle does not come from the editor itself but from something in that page or an associated script. In fact it looks a bit like a jQuery Mobile loading indicator to me.
One thing that may be happening here is something in the application's startup code has been added to call out to server-side logic (ex. a Worklight adapter call). Within the editor, the full preview server is not available so generally only the browser-side resources of an application will be functional. This allows you to use the editor for UI design work and then once you start hooking up to server-side features, previewing of the app would typically switch over to the Mobile Browser Simulator (Run As->Preview) or even native browser testing.
The best recommendation is to look for something in your app initialization process that's expecting data back and put in some temporary development-time mockups for such data. As an example, instead of making a service call to retrieve some JSON data just point to a test .json file in your project instead.
Could be related to this: Worklight Studio Rich Page Editor fails of WL.* call in page load
The short answer is that if you put just about any WL.* calls (even WL.Logger.*) in a page loading handler, it causes the Rich Page Editor to lock up.
If the problem is that you are calling backend resources that aren't available, then the normal timeouts and error handling in your code should keep the editor from locking up. You do have timeouts and error handling in your code, right? ;-)
If this problem can't be debugged easily, weinre (http://people.apache.org/~pmuellr/weinre/docs/latest/) works in the Rich Page Editor. You can see what is in the JavaScript console and if there are any exceptions thrown when it locks up.
winJs application are simple html Applications. Xaml c# provides an interface view where we can look at the design drag drop elements.
Is there a Way to Debug a winJS application like firebug or inspect element in Google Chrome. running every time in the simulator to check whether code is working or not has become a tedious Job. Any alternative please suggest.
Yes there's a kind of firebug as you mentioned But it is also known as Dom Explorer
The DOM Explorer is available only while in debug mode.
Make sure you have the script debugger selected, start debugging (F5), then go to Debug -> Windows -> DOM Explorer.
Here's a link to study the details
Dom Explorer from MSDN
I have a GWT app with a bunch of textboxes. In firefox I would expect that when I type a word in a textbox that I have already typed in and submitted, that firefox would offer to autocomplete that text. But for this GWT app it is not happening.
The ids and the name of the html elements are the same everytime. I don't know if it makes a difference, but I am using UiBinders for presentation.
Also in IE it seems that none of my css stuff is loaded. And when I IE developer tools on my GWT page, it can focus in on any of the textboxes it just focuses on the encompassing DIV around all the textboxes.
The problem with autocompletion is caused by how the DOM tree is created in a dynamic web application, such as the one created using GWT. Basically, all the DOM elements (textboxes, etc) are dynamically created, after the page is loaded. However, AFAIK, the browser only supports autocompletion on "static" elements, ones that are part of the HTML host page. So, for that reason you won't get autocompletion support from your browser in a GWT app. Fot some cases, you can still emulate it via SuggestBox.
You could try including the elements you want autocompletion for in your HTML host page, and then wrapping your GWT Widgets around them - that might work :) But it's not the "prettiest" solution, since you probably want autocompletion for a number of unrelated fields/elements.