«

I have an application that contains many (16) Drop Down Lists that are all
the same width and many Buttons (40) that are the same width. They are
arranged in columns.

This is rendered perfectly in Internet Explorer.

It is a jumbled mess in Firefox, Mozilla, Netscape, and Opera. These
browsers are apparently ignoring the height and width attributes on Drop
Down Lists, Buttons, and Textboxes.

Is there a way to correct this unwanted behavior?

--
-- Thom Little -- www.tlaNET.net -- Thom Little Associates, Ltd.
--

Hi,

this is related to the fact that only IE is considered to be an uplevel
browser. This can be overcome with changes to configuration files which
specify how ASP.NET detects browsers. You'll find the changes described
here:
http://www.asp.net/Forums/ShowPost.a...1&PostID=89874

--
Teemu Keiski
MCP, Microsoft MVP (ASP.NET), AspInsiders member
ASP.NET Forum Moderator, AspAlliance Columnist
http://blogs.aspadvice.com/joteke





"Thom Little" <> wrote in message
news:...
> I have an application that contains many (16) Drop Down Lists that are all
> the same width and many Buttons (40) that are the same width. They are
> arranged in columns.
>
> This is rendered perfectly in Internet Explorer.
>
> It is a jumbled mess in Firefox, Mozilla, Netscape, and Opera. These
> browsers are apparently ignoring the height and width attributes on Drop
> Down Lists, Buttons, and Textboxes.
>
> Is there a way to correct this unwanted behavior?
>
> --
> -- Thom Little -- www.tlaNET.net -- Thom Little Associates, Ltd.
> --
>
>
>

On Wed, 28 Jul 2004 14:39:01 -0400, "Thom Little" <>
wrote:

>This is rendered perfectly in Internet Explorer.
>
>It is a jumbled mess in Firefox, Mozilla, Netscape, and Opera. These
>browsers are apparently ignoring the height and width attributes on Drop
>Down Lists, Buttons, and Textboxes.

Is it that ASP.Net on your server isn't detecting those browsers as
"up-level" ones, and hence rendering the tags for those controls in
the down-level way?

If you put something like the following updated browsercaps section
into the web.config for your site (within the system.web block), those
browsers should be detected as up-level and you might well find that
everything renders ok:

<browserCaps>
<!-- GECKO Based Browsers (Netscape 6+, Mozilla/Firebird, ...)
//-->
<case match="^Mozilla/5\.0 \([^)]*\) (Gecko/[-\d]+)?
(?'type'[^/\d]*)([\d]*)/(?'version'(?'major'\d+)(?'minor'\.\d+)(?'letters' \w*)).*">
browser=Gecko
type=${type}
frames=true
tables=true
cookies=true
javascript=true
javaapplets=true
ecmascriptversion=1.5
w3cdomversion=1.0
css1=true
css2=true
xml=true
tagwriter=System.Web.UI.HtmlTextWriter
<case
match="rv?'version'(?'major'\d+)(?'minor'\.\d+)( ?'letters'\w*))">
version=${version}
majorversion=${major}
minorversion=${minor}
<case match="^b" with="${letters}">
beta=true
</case>
</case>
</case>

<!-- AppleWebKit Based Browsers (Safari...) //-->
<case
match="AppleWebKit/(?'version'(?'major'\d)(?'minor'\d+)(?'letters'\w* ))">
browser=AppleWebKit
version=${version}
majorversion=${major}
minorversion=0.${minor}
frames=true
tables=true
cookies=true
javascript=true
javaapplets=true
ecmascriptversion=1.5
w3cdomversion=1.0
css1=true
css2=true
xml=true
tagwriter=System.Web.UI.HtmlTextWriter
<case
match="AppleWebKit/(?'version'(?'major'\d)(?'minor'\d+)(?'letters'\w* ))(
\(KHTML, like Gecko\) )?(?'type'[^/\d]*)/.*$">
type=${type}
</case>
</case>

<!-- Konqueror //-->
<case
match="Konqueror/(?'version'(?'major'\d+)(?'minor'\.\d+)(?'letters' ));\w*(?'platform'[^\)]*)">
browser=Konqueror
version=${version}
majorversion=${major}
minorversion=${minor}
platform=${platform}
type=Konqueror
frames=true
tables=true
cookies=true
javascript=true
javaapplets=true
ecmascriptversion=1.5
w3cdomversion=1.0
css1=true
css2=true
xml=true
tagwriter=System.Web.UI.HtmlTextWriter
</case>
</browserCaps>


ted.h.
--
Ted Harper (Sydney, Australia)

Thanks to you both and I found the article at Code Project. I have it
working for Firefox (a.k.a. Firebird), Netscape 7.1, and Internet Explorer.
It works for Opera although Opera seems to be an incomplete implementation
and some (many?) features do not behave properly.

Mozilla 1.7.1 has a new format for the string so I added yasc (yet another
special case).

The appliacation I am working on is at www.tlacsharp.net/thom_little

My current Web.config file is ...

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<system.web>

<customErrors mode="RemoteOnly" />

<browserCaps>

<!-- Opera -->
<case match="Opera[
/](?'version'(?'major'\d+)(?'minor'\.\d+)(?'letters' \w*))">
browser=Opera
version=${version}
majorversion=${major}
minorversion=${minor}
frames=true
tables=true
cookies=true
javascript=true
ecmascriptversion=1.1
isMobileDevice="true"
tagwriter=System.Web.UI.HtmlTextWriter
<filter match="[4-9]" with="${major}">
ecmascriptversion=1.3
css1=true
css2=true
xml=true
<filter match="[5-9]" with="${major}">
w3cdomversion=1.0
</filter>
</filter>
<filter match="^b" with="${letters}">
beta=true
</filter>
</case>

<!-- GECKO Based Browsers (Netscape 6+, Firebird, Firefox ...) -->
<case match="^Mozilla/5\.0 \([^)]*\) (Gecko/[-\d]+)?
(?'type'[^/\d]*)([\d]*)/(?'version'(?'major'\d+)(?'minor'\.\d+)(?'letters' \w
*)).*">
browser=Gecko
type=${type}
frames=true
tables=true
cookies=true
javascript=true
javaapplets=true
ecmascriptversion=1.5
w3cdomversion=1.0
css1=true
css2=true
xml=true
tagwriter=System.Web.UI.HtmlTextWriter
<case match="rv?'version'(?'major'\d+)(?'minor'\.\d+)( ?'letters'\w*))">
version=${version}
majorversion=${major}
minorversion=${minor}
<case match="^b" with="${letters}">
beta=true
</case>
</case>
</case>

<!-- Mozilla -->
<case match="^Mozilla/5\.0
..*rv\?'version'(?'major'\d+)(?'minor'\.\d+)).*" >
browser=Gecko
type=Mozilla
frames=true
tables=true
cookies=true
javascript=true
javaapplets=true
ecmascriptversion=1.5
w3cdomversion=1.0
css1=true
css2=true
xml=true
tagwriter=System.Web.UI.HtmlTextWriter
version=${version}
majorversion=${major}
minorversion=${minor}
</case>

<!-- AppleWebKit Based Browsers (Safari...) -->
<case
match="AppleWebKit/(?'version'(?'major'\d)(?'minor'\d+)(?'letters'\w* ))">
browser=AppleWebKit
version=${version}
majorversion=${major}
minorversion=0.${minor}
frames=true
tables=true
cookies=true
javascript=true
javaapplets=true
ecmascriptversion=1.5
w3cdomversion=1.0
css1=true
css2=true
xml=true
tagwriter=System.Web.UI.HtmlTextWriter
<case
match="AppleWebKit/(?'version'(?'major'\d)(?'minor'\d+)(?'letters'\w* ))(
\(KHTML, like Gecko\) )?(?'type'[^/\d]*)/.*$">
type=${type}
</case>
</case>

<!-- Konqueror -->
<case
match="Konqueror/(?'version'(?'major'\d+)(?'minor'\.\d+)(?'letters' ));\w*(?'
platform'[^\)]*)">
browser=Konqueror
version=${version}
majorversion=${major}
minorversion=${minor}
platform=${platform}
type=Konqueror
frames=true
tables=true
cookies=true
javascript=true
javaapplets=true
ecmascriptversion=1.5
w3cdomversion=1.0
css1=true
css2=true
xml=true
tagwriter=System.Web.UI.HtmlTextWriter
</case>

<!-- Internet Explorer -->
<case match="^Mozilla[^(]*\(compatible; MSIE
(?'version'(?'major'\d+)(?'minor'\.\d+)(?'letters' \w*))(?'extra'.*)">
browser=IE
version=${version}
majorversion=${major}
minorversion=${minor}
<case match="^[5-9]\." with="${version}">
frames=true
tables=true
cookies=true
backgroundsounds=true
vbscript=true
javascript=true
javaapplets=true
activexcontrols=true
tagwriter=System.Web.UI.HtmlTextWriter
ecmascriptversion=1.2
msdomversion=${major}${minor}
w3cdomversion=1.0
css1=true
css2=true
xml=true
isMobileDevice="true"
<filter with="${letters}" match="^b">
beta=true
</filter>
<filter with="${extra}" match="Crawler">
crawler=true
</filter>
</case>
<case match="^4\." with="${version}">
frames=true
tables=true
cookies=true
backgroundsounds=true
vbscript=true
javascript=true
javaapplets=true
activexcontrols=true
tagwriter=System.Web.UI.HtmlTextWriter
ecmascriptversion=1.2
msdomversion=4.0
cdf=true
css1=true
<filter with="${letters}" match="^[ab]">
beta=true
</filter>
<filter with="${extra}" match="Crawler">
crawler=true
</filter>
<filter match="; AOL" with="${extra}">
aol=true
</filter>
<filter match="; Update a;" with="${extra}">
authenticodeupdate=true
</filter>
</case>
<case match="^3\." with="${version}">
frames=true
tables=true
cookies=true
backgroundsounds=true
vbscript=true
javascript=true
javaapplets=true
activexcontrols=true
ecmascriptversion=1.0
css1=true
<filter match="true" with="%{win16}">
javaapplets=false
activexcontrols=false
<filter match="^a" with="${letters}">
beta=true
vbscript=false
javascript=false
</filter>
</filter>
<filter match="Mac68K|MacPPC" with="%{platform}">
vbscript=false
activexcontrols=false
</filter>
<filter match="^B" with="${letters}">
beta=true
</filter>
<filter match="; AK;" with="${extra}">
ak=true
</filter>
<filter match="; SK;" with="${extra}">
sk=true
</filter>
<filter match="; Update a;" with="${extra}">
authenticodeupdate=true
</filter>
<filter match="; AOL" with="${extra}">
aol=true
</filter>
</case>
<case match="^2\." with="${version}">
tables=true
cookies=true
backgroundsounds=true
<filter match="^b" with="${letters}">
beta=true
</filter>
<filter match="; AOL" with="${extra}">
aol=true
</filter>
</case>
<case match="^1\.5" with="${version}">
tables=true
cookies=true
</case>
</case>

</browserCaps>

</system.web>

</configuration>



--
-- Thom Little -- www.tlaNET.net -- Thom Little Associates, Ltd.
--

On Fri, 30 Jul 2004 13:22:06 -0400, "Thom Little" <>
wrote:

>Thanks to you both and I found the article at Code Project. I have it
>working for Firefox (a.k.a. Firebird), Netscape 7.1, and Internet Explorer.
>It works for Opera although Opera seems to be an incomplete implementation
>and some (many?) features do not behave properly.
>
>Mozilla 1.7.1 has a new format for the string so I added yasc (yet another
>special case).

Thanks for the reply, and heads-up on Opera and Mozilla 1.7.1.

I had only tested the web.config update I posted (much less
comprehensive than yours) with the current Netscape and Firefox
browsers. We had a prospective distributor for our product overseas
who was interested in our supporting those two browsers "properly" (in
addition to IE), so I updated the browsercaps and tweaked some of our
ASP.Net code accordingly a month or two ago, and I'm pleased to say it
_is_ working nicely now across those three browsers.

Bad news about Opera not working trivially via that same detection and
up/down level rendering mechanism, but so far we haven't had a client
stipulate our fully supporting it. If it does come up as an issue, and
based on what you found, it sounds almost as if it would be easier and
better to work with the Opera developers to get it in-line with IE and
Mozilla/Firefox, rather than special-case our rendering code (and
cross our fingers on the built-in controls) for it if our app turns
out to not render well with it as-is.

ted.h.
--
Ted Harper (Sydney, Australia)

Unfortunately the problem that I thought was Opera-specific is a problem
with all browsers except Internet Explorer. In particular ...

Response.Cache.SetCacheability( HttpCacheability.NoCache );

.... only seems to be effective in Internet Explorer to disable the cache.

Disabling the cache will permit a dropdown list to reset to its original
value as opposed to being updated to the selected value.

--
-- Thom Little -- www.tlaNET.net -- Thom Little Associates, Ltd.
--

"Ted Harper" <Ted.HarperREPEL_SPAM@SPAM_AWAYImpactInvesting.com > wrote in
message news:...
> On Fri, 30 Jul 2004 13:22:06 -0400, "Thom Little" <>
> wrote:
>
> >Thanks to you both and I found the article at Code Project. I have it
> >working for Firefox (a.k.a. Firebird), Netscape 7.1, and Internet
Explorer.
> >It works for Opera although Opera seems to be an incomplete
implementation
> >and some (many?) features do not behave properly.
> >
> >Mozilla 1.7.1 has a new format for the string so I added yasc (yet
another
> >special case).
>
> Thanks for the reply, and heads-up on Opera and Mozilla 1.7.1.
>
> I had only tested the web.config update I posted (much less
> comprehensive than yours) with the current Netscape and Firefox
> browsers. We had a prospective distributor for our product overseas
> who was interested in our supporting those two browsers "properly" (in
> addition to IE), so I updated the browsercaps and tweaked some of our
> ASP.Net code accordingly a month or two ago, and I'm pleased to say it
> _is_ working nicely now across those three browsers.
>
> Bad news about Opera not working trivially via that same detection and
> up/down level rendering mechanism, but so far we haven't had a client
> stipulate our fully supporting it. If it does come up as an issue, and
> based on what you found, it sounds almost as if it would be easier and
> better to work with the Opera developers to get it in-line with IE and
> Mozilla/Firefox, rather than special-case our rendering code (and
> cross our fingers on the built-in controls) for it if our app turns
> out to not render well with it as-is.
>
> ted.h.
> --
> Ted Harper (Sydney, Australia)

Thom Little wrote:
> Unfortunately the problem that I thought was Opera-specific is a
> problem with all browsers except Internet Explorer. In particular ...
>
> Response.Cache.SetCacheability( HttpCacheability.NoCache );

The real problem is that this particular part of the HTTP 1.1 spec is quite
confusing (even disastrous for web application developers). Opera just won't
send another request when the user clicks the back or forward button.

Cheers,

--
Joerg Jooss

Perhaps you know a solution ...

The reason I was using it was that I have a page with 16 dropdown lists of
URLs. Then a list entry is selected a redirect takes you to the page. When
a "back" is issued it returns to the page with the 16 dropdown lists.

The problem is that the selected item is displayed in the updated page of
dropdown lists. What I want is to have the original version of the page
displayed.

Any ideas on how to do this without disabling the cache?

--
-- Thom Little -- www.tlaNET.net -- Thom Little Associates, Ltd.
--

"Joerg Jooss" <> wrote in message
news:...
> Thom Little wrote:
> > Unfortunately the problem that I thought was Opera-specific is a
> > problem with all browsers except Internet Explorer. In particular ...
> >
> > Response.Cache.SetCacheability( HttpCacheability.NoCache );
>
> The real problem is that this particular part of the HTTP 1.1 spec is
quite
> confusing (even disastrous for web application developers). Opera just
won't
> send another request when the user clicks the back or forward button.
>
> Cheers,
>
> --
> Joerg Jooss
>
>

On Sun, 1 Aug 2004 02:31:44 -0400, "Thom Little" <>
wrote:

>Unfortunately the problem that I thought was Opera-specific is a problem
>with all browsers except Internet Explorer. In particular ...
>
> Response.Cache.SetCacheability( HttpCacheability.NoCache );
>
>... only seems to be effective in Internet Explorer to disable the cache.

It may be no-cache overkill (and disabling cache can be annoying to
users if they are used to back-button navigation), but what we have on
every ASPX page is a call to the following:

public static void SetNoCaching(HttpResponse response)
{
response.Cache.SetExpires(DateTime.Now.AddSeconds(-60));
response.Cache.SetCacheability(HttpCacheability.No Cache);
response.Cache.SetValidUntilExpires(false);
response.Expires = 0;
response.Cache.SetNoStore();
response.AppendHeader("Pragma", "no-cache");
}

Between that little lot, our dynamic page output does NOT appear to be
cached by anyone.

ted.h.
--
Ted Harper (Sydney, Australia)

Sorry to report that there was no change.

I installed your suggestion in Page_Load and ...

Internet Explorer - reset back to original
Firefox - no reset
Mozilla - no reset
Netscape - no reset
Opera - no reset

In all but Internet Explorer the dropdown list displays the selected
element.

--
-- Thom Little -- www.tlaNET.net -- Thom Little Associates, Ltd.
--

"Ted Harper" <Ted.HarperREPEL_SPAM@SPAM_AWAYImpactInvesting.com > wrote in
message news...
> On Sun, 1 Aug 2004 02:31:44 -0400, "Thom Little" <>
> wrote:
>
> >Unfortunately the problem that I thought was Opera-specific is a problem
> >with all browsers except Internet Explorer. In particular ...
> >
> > Response.Cache.SetCacheability( HttpCacheability.NoCache );
> >
> >... only seems to be effective in Internet Explorer to disable the cache.
>
> It may be no-cache overkill (and disabling cache can be annoying to
> users if they are used to back-button navigation), but what we have on
> every ASPX page is a call to the following:
>
> public static void SetNoCaching(HttpResponse response)
> {
> response.Cache.SetExpires(DateTime.Now.AddSeconds(-60));
> response.Cache.SetCacheability(HttpCacheability.No Cache);
> response.Cache.SetValidUntilExpires(false);
> response.Expires = 0;
> response.Cache.SetNoStore();
> response.AppendHeader("Pragma", "no-cache");
> }
>
> Between that little lot, our dynamic page output does NOT appear to be
> cached by anyone.
>
> ted.h.
> --
> Ted Harper (Sydney, Australia)