9

I'm trying to understand cases where the critical update currently in Winter '13 orgs might come into play. The description of the update says:

Prior to the Winter ’13 release, text in some Visualforce pages and components might have been generated incorrectly. This markup could contain fragments that should have been escaped (for example, the "<" character generated as "<") but were not. These fragments might be interpreted by the browser as markup rather than as text in the page. This problem has been corrected for all pages with API version 26.0 or later.

I don't have the update activated and I've been playing around with it to see what cases might render the markup instead of escaping it. Here's my simple page (version 19.0):

<apex:page controller="HtmlEscapeController">
  <apex:outputText value="{!text}"/>
</apex:page>

and here is my controller (also version 19.0):

public class HtmlEscapeController {

    public String text { 
        get {
            return '<h1>blah</h1>';
        }
        set; }
}

Based on the update description I was expecting the text to be rendered with the html tags, but it wasn't. I had to add escape="false". So, my question is, in what situations does the markeup not get escaped?

3 Answers 3

9

There are only a few situations where the markup wasn't getting escaped properly earlier. As you can see from your test, the down the middle test worked before and after.

Here is a test case for when the markup wasn't getting escaped and it should have:

[Apex Class] MyController

global class MyController { 
    public String getProperty() {
        return  '<h1> escape me </h1>';
    }
}

[Visualforce Page] MyPage

<apex:page controller="MyController" showheader="false"> 
  <script />
  <apex:outputText escape="true" value="{!property}"/> 
</apex:page>
1
  • Ah, so it is the <script /> tag that seems to be the culprit here? I added it to my test page and voila! Commented Oct 19, 2012 at 19:42
2

I think I found the answer for this buried on page 197 of the Winter13 release notes:

Changes to Escaping Behavior

Prior to the Winter ’13 release, text in some Visualforce pages and components might have been generated incorrectly. This markup could contain fragments that should have been escaped (for example, the "<" character generated as "<") but were not. These fragments might be interpreted by the browser as markup rather than as text in the page. This problem has been corrected for all pages with API version 26.0 or later.

Your organization might contain pages or components that depend on this incorrect processing. These pages need to be fixed. To fix them, use with the attribute escape="false" to generate unescaped text.

For existing organizations, the Critical Updates page shows a pending change. When you have corrected any pages or components that depend on the incorrect behavior, activate the change on the Critical Updates page. You must make this change by the date indicated on the Critical Updates page. See “Critical Updates Overview” in the online help for details about managing critical updates.

If your organization contains pages or components with the problem installed from managed packages, you might need to contact the package’s supplier to obtain a newer, corrected, version.

2
  • 1
    That is basically the same text as on the critical update. I'm curious about under what situations "these fragments might be interpreted by the browser as markup rather than text". I've tried to get it to come through as markup, but haven't been able to. Commented Oct 18, 2012 at 21:33
  • @DanielHoechst you're right, still not much to go on here. I have a question out to my premier support account rep to see what details he can turn up. If I hear anything more I'll update this. Commented Oct 18, 2012 at 21:42
1

Check what api version your visualforce page is on. If it's 26 it will always behave in the new fashion. If it's less than 26 it should behave the old way until you've activated the critical update.

3
  • I should have mentioned that in my testing, I changed the API of both the page and controller to 19. Commented Oct 17, 2012 at 17:41
  • Looking back at the text from the official statement, there are a lot of "might" and "coulds" in there. Perhaps it wasn't that outputtext globally didn't escape things, but just in certain circumstances which aren't listed in the explanation. Commented Oct 17, 2012 at 21:10
  • Yes, that was my thought too. They used a specific example with <, so I thought I could get it to work. I was just curious what the scenarios might be. Commented Oct 17, 2012 at 22:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .