I've a legacy app that features a DND from a popup window to the main one.
It works fine in IE 8 but not in any of the newer versions of IE. The effect results in the drag ghost image being stuck in the source window and not going away after the drop had occurred.
Some debugging did in fact confirm that the 'mouseup' event does not get propagated back to the source window. What can be done to fix it? Many thanks!
ITs a bit hard to begin to answer your question without some code....
use the File>Properties menu to find out which IE security zones the two windows(domains) map too...IE uses a different security model to other browsers... drag/drop is probably not allowed between local web files (using file: protocol) and internet or intranet sites.
Have you used the Dev tool yet to debug it? If you are using showModalDialog (which normally disables context menus) you can right click on a link (a) or input element to display the context menu so you can display the debugger for showModal content page.
If possible include a link to your website or a mashup (jsfiddle) with your questions.
Related
First foremost: I am aware that this is not a general Typo3 bug/error per se, as I have working installations. I am hoping for hints/help in finding the error in this installation, as it's way too big to just set it up as a new installation.
I have an erronous Typo3 10.4.17 installation (updated to 10.4.x, no fresh install)
Problem: Edited elements in workspace are not shown in the Frontend preview (opened via "Show webpage" or other basic means in BE) nor in the BE View-module.
Additional info #1: They are however shown when preview links are generated via "Generate page preview links" and those are viewed.
Additional info #2: Changed elements only become visible after publishing them & clearing Cache
Additional info #3: Clearing any Cache does not make them visible in the preview
After comparing all settings I could think of to another working installation I decided to delve into the core in search for a hint/solution and got stuck there at following point:
TYPO3\CMS\Workspaces\Controller\PreviewController
Line 130 $workspaceItemsArray = $this->workspaceService->selectVersionsInWorkspace()
As well as:
TYPO3\CMS\Workspaces\Service\WorkspaceService
Line 220 public function selectVersionsInWorkspace()
At this point my edited workspace version of the element does get retrieved. selectVersionsInWorkspace() does get called when viewing the preview.
While the PreviewController does not further filter the staged elements, they are not displayed in the Preview.
I am looking for any hint as to where selectVersionsInWorkspace() might still be filtered or other hints as to possible reasons/solutions for this problem that I may have overlooked.
Just when I decided to post to SO a co-worker found the reason...
As it's a big installation we use a dev-domain as admins and each website (over 100) have their own domains which are also set as base in the Site-config.
Only when the preview is opened as either the base or a baseVariant the workspace-elements are displayed at all. In older version the elements would still be displayed when opened via other associated domains, just sometimes not 100% accurately.
Letting this stay in case anyone ever has a similar problem and is hopefully able to find this.
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
Any help/advice on this would be greatly appreciated.
I'm looking for what I would consider a standard setup for modern day web design/development. Basically I have a dual monitor setup and I would like to code on one screen and have the changes displayed in real-time on the other screen.
Up until yesterday I was using jsbin in this way and it was working great. I had one browser setup with the coding stuff (HTML/CSS/jQuery) and I then had another separate browser open on the second monitor which updated instantly as I typed. So if I changed a CSS rule for example it was shown in real-time on the second monitor without me having to do ANYTHING. No saving, no refreshing, no switching tabs - NOTHING.
However, for whatever reason jsbin now refuses to update in real-time and it will only show the code changes if I manually refresh the browser. I've emailed jsbin about this but they can't diagnose the issue.
So what I'm looking for is either an online alternative, or a local alternative. However, everything (and I mean EVERYTHING) that I've tried so far can't do what jsbin did.
dabblet.com, jsFiddle.net, liveweave.com, codepen.io, cssdeck.com etc
But all of the above don't offer a second tab/browser that I can move to the second monitor to show the code updates in real-time which is the most important thing.
Surely there must be an easy solution to this? Is it not common to code in this way on 2 monitors whilst developing a website? I'd really appreciate any help on this.
Many thanks
Ben
For local option, Brackets has Live Preview mode.
After you open your project or file for editing, select File -> Live Preview
It launches a browser window, then your changes are reflected as you type, no save or browser refresh needed.
I use Liveweave with my dual monitor setup. I keep the HTML/CSS in my left window/monitor and the JS/Preview in my right monitor. Works great!
When using chrome developer tools, it appears that each app window (and the background 'page') has its own javascript context (space of objects, thread of execution), and yet the createdWindow callback of chrome.app.window.create apparently provides direct access to the objects of the 'other' window that was just created.
Given that, I'm unclear on the best way to communicate between windows; e.g. if I open a second window to act as a dialog box, when the user clicks OK to save changes, should I be using postMessage, sendMessage, or just call a function on an object in the main window. I've looked at the messaging samples, and they seem focused on communication between two different apps, or between an app and an extension.
So, I'm seeking a clear description of the memory and execution model within one app. Are there really separate contexts, or is it just one space of objects, with one thread of execution? What is the best way to communicate between windows of the same chrome app?
That is a great question James!
Multiple chrome windows are not completely separate. They share a single thread and object space, however the window object is different for each. In javascript unscoped references to things are looked up on the current window, so this makes the windows appear to be different object spaces - but they are not really.
So, you can reach into another window and execute a function there, or manipulate state in other ways (e.g. set a variable on another window to a function from the current window) and it is acceptable and supported.
You might find the chrome.app.window.getAll() and chrome.app.window.get() methods useful. They are however new to Chrome 33 which is not yet in the stable channel.
As an alternative you could hold an array of opened AppWindow objects in the background page context.
You can then get a reference to the background page context from any window using the chrome.runtime.getBackgroundPage() method
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.