It might be nice to give the teacher/editor a choice, as they are given for other types of resources.

Just for reference, the issue is XHTML strict compliance which disallows targets.

http://moodle.org/mod/forum/discuss.php?d=75515

RSS block should just be changed to use the link_to_popup_window() function so that our nasty hack can be leveraged.

Be aware of the cleaning of the data that goes on ... JS from our hack will not make it through the clean, so things need to be cleaned first before the call to that function.

Unfortunately link_to_popup_window seems to be focused on internal only urls.

Attaching a patch to fix the issue, like Martin says clean_text will strip the javascript hack, so need to remove that call.

Unfortunately get_rss_by_id() is messy..

Hi Petr,

I'm assigning this issue to you - I wonder if you could review my patch. We need to remove a clean_text so that our js hack can make its way through to be outputted.

get_rss_by_id is messy & could do with a check to see that everything is properly cleaned, or a refactor

Users have complained reminding me of this issue.

I've had another review of the the cleaning and it seems everything is covered so i'm going to commit the fix.

I've fixed this in CVS for 1.8 stable and HEAD.

Note that forcing anything to open in a new window poses an accessibility problem.

In MSIE7, for instance, popup blocking is enabled by default. Some users might not figure out how to disable this. Worse, screenreader users might be denied information on how to disable this.

Accessibility problem: As the person who raised this as an issue I accept this is a potential issue.

Nicklas do you have any suggestions as to how this might be addressed? I can only think that this might be linked somehow to the "screen reader" option in the user profile so that if set to "yes" the behaviour here would be open in same window.

If this was possible then thought would need to be given to how to deal with other pop ups e.g. glossary, secure quiz, resources.

Dan, Nickas, other watchers any ideas......?

The screen reader option is not very prominent, and probably should not be relied upon to solve accessibility problems (at least as things stand now). But besides that, preventing opening new windows might be a good idea when the option is turned on.

I think adding a configuration option for this behaviour in the RSS block is a reasonable solution.

(Given all the usability and accessibility problems caused by forcing new browser windows, i would rather see the possibility of doing this removed everywhere in Moodle. But i doubt that would be appreciated.)

I don't agree with your RSS block option suggestion. This forces one type of behaviour or another for all users. The issue of the opening of a new browser window is not one that is a problem for all users but is specific to individual users, therefore any option that affects this must be configurable at individual level IMO.

Yes, but something is only accessible if it is accessible by default.

Therefore i suggest the default to be opening in the same window, and having the option for the case when there are users that already depend on the old behaviour.

Agreed.

The best solution (as far as I can see) is still in the user's profile though, and an array of options for this type of thing would be a bit messy.

Whatever, getting some consistency with the other pop up windows could be tricky.....

I agree this should be optional - I don't like popup windows

It would be good to have an audit of all existing popup windows and see how this can be dealt with. I'm not sure what the best way to do this would be (yet another tiny complicated user profile field would seem complicated).

In any case, I think someone should create a new issue for this and link it to this one as it doesn't just effect the RSS block and would need to be applied consistently to be useful.

Ray, would you elaborate on how a profile setting would work and how it will be used, as you see it?

We are talking about this issue in MDL-17922