Odd webform behavior after clienteidmode set to static

Question

0.00/5 (No votes)

See more:

Hi there,

I am working in a webform that was working as expected prior changing its ClientIdMode to Static. I obviously had to make several adjustments to code since the plethora of UpdatePanels in it decided to ignore the set AsyncPostBackTrigger or at least so it seemed to me.

Any how, after adjustments, almost everything came back to normal except for an odd behavior, which I'll try to describe. One of many present buttons calls its code behind code, and updates both, the DB and UI as expected. It event sets the focus on the desired control.

protected void lkBtnOkDcto_Click(object sender, EventArgs e)
{
...
    txDocNum.Focus();
}

I can event start typing into it as if everything was peachy.

Here's the catch. When I hover any control (button, linkbutton, etc) with the mouse, all CSS changes or standard behavior such as link preview, pointer settings, etc. simply go away. I have to click anywhere in the page for it to "work again".

Any ideas?

What I have tried:

I have review the code which sets the focus, updates each a every involved UpdatePanel, and every control (label, textbox, ddl, etc.) get properly set.

One thing I noticed; when I am forced to "click" anywhere in order to "reactivate" the mouse, the focus is sent to another control, which does not have autofocus set, nor its focus is ever set in code behind.

Thanks for your input.

Posted 15-Nov-18 10:28am

alexvw

Updated 19-Nov-18 3:55am

v2

Add a Solution

Comments

Vincent Maverick Durano 15-Nov-18 16:44pm

I wouldn't be surprised if your getting odd behavior because UpdatePanel is just "evil".

How are you defining your CSS? Your issue is more on mouseover right? If so, then look for any script/css in your project that relates to mouseover thing. It could be that you are referencing the old ids instead of the new static ids.

alexvw 16-Nov-18 9:44am

Hi Vincent, thanks for your input.

I did verify all css/javascript and code behind, without any luck. Any control reference was always set to control.ClientId (not using hard-coded ids).

I just can't pin-point why the focus is set (where I want), keystrokes work as expected, but not the mouse. I implemented javascript to allow navigation using arrow keys, pressing Enter, Tab, and they all work just fine.

The issue is limited to the mouse pointer; also noticed that no matter where I set the focus using the keyboard, the very next mouse click will always send the focus to the same unintended control.

Will continue to scratch my head!

Vincent Maverick Durano 16-Nov-18 11:22am

Does this behaves in all browsers or it's isolated?

alexvw 16-Nov-18 12:20pm

Good question! Vincent.

I can now tell how tired I am; it did not occur to me to verify that (which I usually do). And it is constant in all Browsers = it is not the browser, it is my code. (Tested: FF, Opera, Chrome, Vivaldi, Brave, Safari, IE, Edge)

There must be something somewhere I am just not being able to see now (tunnel vision I hope). I also noticed that several bootstrap classes: col-this, col-that, in some sections are also giving trouble (they used not to). This must be something I did or did not do after changing the ClientIDMode, for it was not like that.

I now know I must not look for odd things, but to review the entire Id situation (and the ViewStateMode, which I have also been messing with).

Thanks for your insight. Have a great weekend.

Cheers!

ZurdoDev 16-Nov-18 13:24pm

You need to use the browser controls and debug it and find out what is happening.

alexvw 19-Nov-18 8:09am

Hi there ZurdoDev,

I have; but cannot pin-point the issue; as previously explained "...keystrokes work as expected, but not the mouse. I implemented javascript to allow navigation using arrow keys, pressing Enter, Tab, and they all work just fine."

The issue remains; the mouse seems to become "inactive", forcing a click to "re-enable" it.

Thanks for your input.

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

alexvw · Answer 1 · 2018-11-19T03:56:00

Hi,

Thanks to the input offered by both: Vincent Maverick Durano, and ZurdoDev, I found the root of the problem!

It was a div tag inside an updatepanel (Vicent, you are right, they are "Evil"), which simply decided to ignore the Update() method being invoked from code.

divClickOut.Visible = false;
UpdPnlBackDrop.Update();

Since the div is transparent a has not effect on tab, etc. key-navigation, its presence was not obvious.

On the other hand, as ZurdoDev suggested, I did use the browser's debug tool (again), to inspect scripts, html, etc, but overlooked the simple, yet effective right-click => "Inspect Element" option.

These ideas allowed me to detect the problem of this "odd behavior"; now, I'll get on fixing it.

Thank you guys.