We have an application running flex sdk 4.5 and have recently encountered an issue with textInput fields which we have not been able to reproduce on our end for the better part of a month now.
Here are the symptoms:
Users opens an input form which contains several input fields (combo boxes, calendars, text inputs, etc)
User clicks inside a text field
Users types (obviously!)
** Nothing appears in the text input - we have validators on some of these fields and they do kick in properly (ie. user sees red box around textInput disappearing)
User moves cursor outside of text input field and text appears
Give or take, this is the test case we've been provided. We have been unable to reproduce this and I'm reaching out to see if anybody has heard of issues like this in the past.
They are running our flex application in the following environment:
Windows XP SP3
IE 7.0.5730.13 (locale = en-gb)
Flash Player 10.3.181.14
Upgrading either of these components is not an option. Installing the flash player debugger is not an option either.
Now we've setup a pc exactly the same way as they have on their end and still haven't reproduced. So we're really stuck at this point :)
Any suggestion is greatly appreciated. I'll provide any additional info needed.
-Marc
Feb. 2nd 2012 - Update
As I noted in my comment reply to shaun, it seems our customer was more or less precise in their description of the issue. We ran a webex session with them this morning and actually saw the issues first hand.
Here's what happens:
- User loads our application via its url
- User is able to input data and pretty much do any function for a 'random' time period
- All of a sudden, the issues start (there are more symptoms than just the one I originally mentioned):
1. Users type in text input fields and they won't see the text appear until they move the cursor out of / into any other component (could be entering an hbox, exiting a text input field, etc)
2. Combo boxes behave more or less the same. They can drop them down, but then the mouse wheel no longer refreshes the list. It actually scrolls in the background, but until the user moves the mouse, the list does not refresh
3. We also communicate between the server and client via an amf channel. The events make it to the client, but again, they won't see the screen refresh until they move their cursor.
So basically, the application still seems to work, but the screen is no longer refreshing. Could it be something to do with an invalidate / update of the display list that doesn't kick in? We'd like to get them to install the debugger version of FP, but that doesn't seem to be an option.
Another thing to keep in mind: they have a VERY bad internet connection. They average around 1-1.5mbps (megabits) which is enough for our app, but I just thought I'd let you know.
We learned that they also use a Citrix presentation layer to deploy IE 7 to the end users. We've received confirmation from the end user that even if they launch IE on their workstation (not through citrix), they get the issue also.
Another note is that we've seen no errors in our web server, jboss or application logs...
So that's the update I've got... anyone have more thoughts on this? We've more or less discarded the fonts being an issue at this point since the issue affects more than just 'fonts'. Is everything on the screen not updating anymore.
Related
I'm new to an approximately 50K-line Java project using JavaFX, and I'm getting a bug nobody else in the group seems to be able to duplicate. Unfortunately I can't share any code, so this is just a hope that this is a familiar issue to anyone else, or that there are suggestions about how to think about and solve this problem.
The application itself is a launcher with five different modes. The minimum working system requires running two different instances of the application and starting mode #1 in the first and mode #2 in the second. The two communicate with each other over IP.
Mode #1 works fine, stays open indefinitely; at any rate, I haven't been able to make it close unexpectedly. Mode #2 is the problem. After opening Mode #2, if I click on any other window, taking focus off of it, the window disappears within a second or two. I get no error message or any other symptom. The eclipse console just reads at the top. If I don't click elsewhere, it runs several minutes at least without comment.
I have no idea how to go about solving this problem. I can't seem to use a debugger because it doesn't seem to hold onto memory after crashing. There's nothing about crashing when the focus is taken off that matches up with any of my knowledge.
It's a simple window, two buttons, a menu, and an output text box.
With these clues, do you have any suggestions about how to proceed?
I am a recent Access 2010 user from 2003 (don't judge me), but I have having a major problem with the ribbon not working as a reasonable person might expect. I'm stuck having to constantly switch to the File tab to get the right options to enable or display which is extremely annoying. What is the problem here?
(Sorry this is my first post and I do not have enough cred to embed pictures)
Issue 1
When I open a query in design mode, the ribbon opens with almost all the options disabled
http://i.imgur.com/hbNtGUX.png
Select, Make, Append, Update, Delete queries all look like this when I design them. I have to click on the File tab, then back to Design to get the full breadth of options.
For macros, the Design tab shows those options but they are all disabled. I have to switch to File and back to get them to enable.
Issue 2
If I click the grid to preview results, the ribbon does switch to show all the proper table view options. This is good! It is what I would expect.
Unfortunately, when I go back into design view, the ribbon stays in the same configuration only it disables most of the table view options. That makes since since I'm looking at the design and they don't apply, BUT it should be showing me design options instead. Notice that the design tab doesn't even show up
http://i.imgur.com/9gAUi4r.png
Again, I have to click on File, then Home before it puts me back into the Design tab with the full breadth of options.
Edit: Version: 14.0.7106.5001 (32-bit)
Access was already at SP2 version, but I did notice that windows update wanted a restart. The log show 7 office & access updates installed. The version number in access didn't change but now the ribbon behaves normally. I had restarted previously so I believe the issue was resolved with the recent office updates and a restart.
A user complains they can't paste into one particular text box on a form and that this is a change in behavior that occurred three months ago. I can't reproduce the error. I've tried long text, short text, plain text, formatted text, everything works. I did fix some poorly formatted HTML, but it didn't change their problem.
The user and I are both using XP/IE7. The application uses a proprietary MVC framework with C# on .NET 1.1. The UI only works reliably in IE. (I tried Opera and the paste works, I can't get logged in with Firefox to get to the screen.)
Any ideas where to start?
Thanks!
Edit - here's dialog I had with the user that didn't bring to light any issues.
You were actually on the right track
in asking about the firewall, because
you are trying to identify something
that is different between me and you.
Here's some other potential
differences.
Maybe we aren't doing it the same way:
Do you use keyboard shortcuts (Ctrl-C,
Ctrl V) or the context menu (right
mouse click and select copy/paste)?
Maybe our computers are different:
What hardware (Windows/Mac), operating
system (XP, Vista, etc.), and browser
(IE, Firefox, etc.) are you using?
Maybe our understanding of the problem
is different: Do you not see the text
when you paste it in, or is it not
being saved?
Maybe what we are copying from is
different: I copied something from
Bugzilla and something from notepad.
Both are plain text. I need to try
formatted text, like from a PDF and
from Word. You need to try plain text.
This may be actually a user training issue. If it were me, I'd use something like crossloop to watch the user interact with the page. If you can see what they are actually doing (not what they SAY they are doing) then you have half a chance at reproduction of the issue. Based on your description, it is very likely not an issue with the software, but a PEBKAC situation with your user.
Notes on Crossloop
We use crossloop with our clients and our developers in training. Basically you install the software (very easy) on both your computer and the end user's computer. The end user then authorizes you to "see" his machine by sending you a connection code. Once connected, both you and the user can move the mouse/type/see the other person use the mouse.
It would be like a remote desktop or vnc session, but much easier to get up and running across firewalls and without too much setup/config headache.
It is also a free download, and a free service (the last time i used it anyway).
Suggested course of action
Install Crossloop on your machine and familiarize yourself with it. (maybe do a trial run connect with a co-worker)
Call user and ask if they would be willing to show their issue to you directly via some screen sharing software.
Walk them through the install and connect of Crossloop.
Instruct them to show you the issue.
Watch for glaring errors, etc.
Hopefully see either what the user is doing wrong, or what conditions the bug manifests itself.
The following code was known to be working three weeks ago. In the interim we have installed IE 7 and a bunch of security patches. The ultimate question will be, does anyone know how to restore the old behavior?
Scenario
We have the following JavaScript code in web page 1 (let's call it foo.aspx), that is invoked on a button click:
window.open("http://Foo/App2/bar.aspx, "_blank", "titlebar,status,width=650,height=600");
The second web page (bar.aspx) is then supposed to open on top of foo.aspx. The user does some stuff, and when they click a button bar.aspx writes some values from bar.aspx back into fields on foo.aspx using JavaScript via window.opener.document, addressing each element individually and modifying its innerText. Then the user closes bar.aspx and there's foo.aspx where they left it, except now it has the values from bar.aspx in certain fields, and the user goes happily on their way using foo.aspx. This has been working for over two years.
During the last two weeks we've applied a bunch of security patches and upgraded to IE 7. Now the behavior is this:
If I am testing and simply navigate to foo.aspx directly, then upon clicking the button bar.aspx opens and then suddenly the focus switches back to foo.aspx with a popup dialog with "The webpage you are viewing is trying to close the window. Do you want to close this window? " If I choose "No", then foo.aspx stays alive, I have to Alt-Tab to get back to bar.aspx, and after that everything works as before. However, this is going to be a pain for the users. Note: NOWHERE IN foo.aspx NOR bar.aspx IS THERE A CALL TO THE close() METHOD!!! So I don't understand why the popup says what it says.
If I access foo.aspx via the application, which means it has been opened programmatically and not explicitly by the user, then bar.aspx opens and you can see foo.aspx disappear (close) behind it. Then bar.aspx gets JavaScript errors because the window.opener is no longer available.
Secenario #1 is non-optimal but at least would be a valid work around (if somewhat of a user training issue to train them to hit "No" and then Alt-Tab, where before none of this was happening. Scenario #2 is non-optimal in the extreme, given that the whole purpose of bar.aspx is to write those values back to foo.aspx.
Other things to note
Now that we've installed IE 7 and the subsequent Active Directory policy changes, the behavior is happening as described even on IE 6.
Both foo.aspx and bar.aspx run on the web server, on the same web site, but in different virtual directories. These are internal application accessible only from inside our network by authenticated users.
Having the server in Intranet zone (where it normally is) or in Trusted Sites makes no difference. I can see no settings in either Zone nor in Advanced Settings that would apply to this behavior, and both the Intranet and Trusted Sites zones are set to be extremely liberal in their policies, especially around script behavior.
I can make any changes I need to in bar.aspx and its client-side scripts, but am limited to only being able to change the button click JavaScript code in foo.aspx (that page is supplied by a vendor, whereas bar.aspx is internally developed).
I reiterate that other than the updates through window.opener.document, foo.aspx is not touched by bar.aspx, and certainly there is no attempt to invoke close() on it.
So, the question remains what in IE 7, or more likely in a security patch, would have broken this? We have a sister shop that is running the same code on IE 7 and they have not reported this issue. So it seems like it has to be something environmental, and right now I keep thinking it must be a patch that got applied. I would take a KB article, IE setting, registry hack, JavaScript change or anything else to fix this.
Thanks for any and all suggestions.
it might be a typo but there's a missing " after the bar.aspx in the sample code.
Opening a window programatically and setting the name to _blank, why are you doing that?
I'm not saying that has anything to do with your issue, but it's probably not a good idea.
It is odd, first thing I would do is fix up a couple strange things in the code so far.
Use an absolute path such as "/App2/bar.aspx" without the protocol or server name since the apps are on the same server.
You can't actually control the titlebar or status bar outside the intranet zone so remove those values from the options list.
Is the pop up blocker closing the pop up window?
If I have a decent size asp.net page open in Source view, and hold down the Up key or Down key to scroll through it, it will periodically get "stuck". It will stop on a line for a few microseconds, and you can see the screen flash, like it's trying to catch up with what it's trying to do behind the scenes. In my two-monitor setup, I'm working in monitor 2, and you can see the icons on the desktop on monitor 1 flash. It's annoying because I invariable overstep lines and have to move back and forth, constantly correcting for the lag. Any idea what it's doing as I cursor through the code? Anything I can turn off to stop this from happening? (Slowing down my key repeat rate is not an option.)
It's possibly the property pane - this was a big issue in VS2005, and VS2005SP1 not only added a feature to turn this off, but turned it off by default, however it looks like they've removed the option to turn it off in VS2008.
Scott Guthrie had a post on HTML Source Editing Performance in VS2005 SP1.
Closing the property pane may well solve the issue if you don't really use it all that much.