Friday, May 11, 2012 2:42 PM
I have an ASP.NET project that displays a paragraph with <BR /> tags. The line breaks appear perfectly in IE9 when running from my desktop with Visual Studio 2010, but when I publish it to an production server (running IIS7), the break tags are ignored.
If I use Chrome or Firefox, it the page breaks appear regardless of whether its being run in production or on my desktop.
I've toyed with compatibility mode to no avail. Any ideas what may be causing this?
Friday, May 11, 2012 4:51 PM
If you have a URL we can visit then please post it. If not then consider to post the minimal source code of the document as received by IE allowing us to reproduce the problem.
Also tell us whether the page is served as text/html or as application/xhtml+xml or which Content-Type it is being served with from the production server. When you hit F12 in IE 9, what does browser mode and document mode show?
MVP Data Platform Development My blog
Friday, May 11, 2012 6:34 PM
Thanks, Martin! Sorry, it's an internal application, so I don't have a public URL to send.
You did make me take a closer look, however, and it appears that I'm dealing with an entirely different issue. For some reason, the <BR /> tags aren't making it to the browser to be rendered in the first place—well, at least not in IE9 on our production server.
My page uses AJAX. When someone double-clicks a record, it opens a form to display the details of that record. Some of those records have line breaks which appear as "\n". So, when the record is opened, I call a server-side function that replaces those with <BR /> tags and ships the data back to the client. I know the call is being made successfully, because there are other lookup fields where I translate numbers into data strings, and those are getting piped back to the client successfully.
Now I just need to figure out why IE9 is the only browser taking issue with this ... and only when I publish the app in prod.
For what it's worth, my page is as follows:
DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
Friday, May 11, 2012 7:41 PMjQuery version?
Monday, May 14, 2012 5:46 PM
As far as I know, I'm not using jQuery. I'm using ExtJS / EXT.NET.
Monday, May 14, 2012 11:15 PM
theres not much we can do on our end without viewing and debugging your code....
In IE9 press f12 then select the networking tab and click start capturing....
examine the response content returned from your ajax requests.
Alternatively download fiddler (http://fiddlertool.com )
IE browsers remove exogenous <br/> tags...
will be rendered as
the common design pattern for <br/> is within <p> blocks or as a vertical spacer between block elements.
Tuesday, May 15, 2012 1:06 PM
Thanks, Rob ... the capturing feature is pretty nifty! I didn't realize that was there, so I marked your response as "helpful".
I'm not doubling down on the <br /> tags, so no worries there. Also, the <br /> tags I'm using are within a DIV, which I would consider a block element, so I'm not terribly concerned about that either.
Doing a trace confirms that the <br /> tags aren't being returned from the server at all (at least not when using IE9), which doesn't make a lot of sense to me. How can the same server return breaks for one browser and not another?
Oh, well ... if I uncover any secrets, I'll post back here.
Tuesday, May 15, 2012 7:46 PM
I had a look at Extjs at http://www.sencha.com/ and found it uses userAgent sniffing....there is also v4 available....
again.... display the Developer tool and toggle the Browser and Document modes to emulate different versions of IE and use the networking tab to inspect the ajax requests and responses..
you can also use the Developer tools, Tools>change user agent string menu to toggle different UAS strings.
have you tried the sencha support forums?
- Marked As Answer by eric v. _ Wednesday, May 16, 2012 1:07 PM
Wednesday, May 16, 2012 1:07 PM
Marking your response as answer, since it helped me figure out what was going on ... but the exact answer is that IE9 was displaying all of our intranet content in compatibility mode. Using your suggestion, I was able to observe this, and once I turned it off, everything was fine!
For posterity's sake, this can be accomplished by hitting ALT to display IE's menu and selecting Tools | Compatibility View settings. Then, within the Compatibility View Settings dialog, make sure that "Display intranet sites in Compatibility View" is unchecked.
I'm still not sure why compatibility mode was screwing this up, but it was.
Wednesday, May 16, 2012 9:46 PM
use the x-ua meta IE=Edge to over-ride your corporate intranet compatibility view settings.
your suggestion may break all of your other intranet sites.
I told you Extjs uses UAS sniffing.... the bug is in their shims.... we whent through the same problems with jQuery $.browser.
I think you've blown your money investing in Extjs.