Closed Bug 652614 Opened 9 years ago Closed 9 years ago

Mangled crash-stats URL in bugzilla comment

Categories

(bugzilla.mozilla.org :: General, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: alex_mayorga, Assigned: dkl)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows NT 6.0; rv:6.0a1) Gecko/20110425 Firefox/6.0a1
Build Identifier: 

https://bugzilla.mozilla.org/show_bug.cgi?id=642117#c0 contained 4 crash report links that are now broken.

Reproducible: Always

Steps to Reproduce:
1. Go to https://bugzilla.mozilla.org/show_bug.cgi?id=642117#c0

Actual Results:  
Crash links are broken.

Expected Results:  
Crash links work.
There's another now broken link at https://bugzilla.mozilla.org/show_bug.cgi?id=642117#c6
Yep, definitely broken. They all have U+FFFD (Unicode replacement character) in them.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is due to the way custom regexes are used in 4.0 to do custom linking in bug comments. Due to a bug I have seen in the past but never quite figured out why it is happening, some links are getting re-formatted more than once and therefore breaks the link. I may need to revert to the old way of doing these til we can find a proper fix for 4.0.

dkl
Assignee: nobody → dkl
Status: NEW → ASSIGNED
Fixed now. Please reopen this if the problem still persists. Otherwise mark as VERIFIED.

dkl
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
The patch has been backed out as it was broken.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Duplicate of this bug: 653754
Summary: Links on description of bug 642117 broke after Bugzilla update → Mangled crash-stats URL in bugzilla comment
Having not looked at any of the code yet, are we scanning for breakpad crash IDs first before we scan for URLs?  If so, that would cause this problem.  Should be scanning for URLs first.
reasoning for comment 8: when we scan for replacements in the bug comments, we replace a replaced item with a token, and not it's replacement, and add the real replacement to a token table.  When all of the replacement scanners have completed, we than go back and replace all of the tokens with their replacements.

The problem is that a breakpad ID that is also contained in a URL, even after that token has been put there, still looks like a URL.  And the URL scanner will then replace the URL, including the token, so the breakpad replacement token is no longer there, if the URL scanner runs after the breakpad scanner.
Backing out the feature until a suitable solution can be found as this is causing dataloss.

dkl
Ok I found the solution using negative lookbehind in the regular expression that only matches the strings if not already in an URL. I am committing now and should be in the next code update.

dkl
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
I still see the broken links on bug 642117, would they eventually appear or do I hunt them down from about:crashes?
Not yet. There hasn't been a new code update since I closed the bug (maybe I should have kept it open?). But give the amount of churn with fixing regressions in 4.0, it won't be long, maybe even today.

dkl
I just did a push about an hour ago, if it hadn't already been live before it should be now.
Status: RESOLVED → VERIFIED
Works, good job, thanks!
Component: Bugzilla: Other b.m.o Issues → General
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.