If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Email address in an article breaks internal links



Knowledge Base Software
8 years ago
7 years ago


(Reporter: Underpass, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: workaround in comment 2, URL)



8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; it; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: 

Alice Wyman has reported 


that the article 


has broken internal links. I tried to de-linkify the email address examples@examples.net writing it as 

examples @ examples.net

and the problem does not occur anymore. It sounds like one of the last updates of the platform is responsible of this behaviour, yet it's hard for me to tell which one.

If I remember well, this is the only article to have an email address.

Reproducible: Always
Probably a side affect of bug 436105.
I'll do a query on articles that have an email address.
Ever confirmed: true
Looking at <https://support.mozilla.com/en-US/kb/Firefox+35+article+tracker>, the "Changing the e-mail program used by Firefox" is the only one that had this problem, because the email address was in the summary.

The workaround is to use the np-parse (~np~) tag.
Old: __examples@examples.net__
New: __~np~examples@examples.net~/np~__

Leaving this open, so we can get a fix, rather than asking contributors to workaround it.
Whiteboard: workaround in comment 2

Comment 3

8 years ago
The internal links in http://support.mozilla.com/kb/Changing+the+e-mail+program+used+by+Firefox are still broken.  So are links to the article itself, created by entering "((Changing the e-mail program used by Firefox))" in  forum threads or in other KB articles, as I previously reported in the Contributors forum topic linked above. 

Also, the problem is NOT shown in the staging copy, http://support.mozilla.com/kb/%2AChanging+the+e-mail+program+used+by+Firefox even though the content is the same.
The fact that it doesn't show up on the staging copy is really interesting. I wonder this is being caused by a translation of the article that is not yet approved for the KB.
Re-syncing the staging copy with the KB version by making an edit, but not really editing any content, fixed it.

I did notice that the German version was created the day before comment 3.

Comment 6

8 years ago
The problem is back again.  See my reply in the Contributor's forum thread (I've included a screenshot): 

Comment 7

8 years ago
The workaround in comment 2 no longer works?
From what I can tell, the workaround works, but issue is re-introduced by something other than tikiwiki markup (search indexing?). So if we edit the page with that workaround, the problem appears fixed. But after a certain amount of time, the problem comes back, without the article having been edited.
-->KB Software
Just going through open article bugs.


8 years ago
Component: Knowledge Base Articles → Knowledge Base Software
QA Contact: kb-articles → kb-software

Comment 10

8 years ago
I haven't seen the issue since my July 20 2009 edit to work around the bug by moving "examples@examples.net" further down in the opening paragraph (to get it out of the "summary" area).
We have special summeries now, but it shouldn't be an issue anyway, please reopen if it still happens.
Last Resolved: 7 years ago
Resolution: --- → FIXED
I just removed the <nowiki> tag from the email address in <https://support.mozilla.com/en-US/kb/Changing%20the%20e-mail%20program%20used%20by%20Firefox> and everything seems fine.

You need to log in before you can comment on or make changes to this bug.