Closed Bug 1361876 Opened 8 years ago Closed 5 years ago

Implement RegExp Unicode Property Escapes

Categories

(Core :: JavaScript Engine, enhancement, P2)

Product:
Core
Component:
JavaScript Engine
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox60 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- affected

People

(Reporter: leonardo.balter, Unassigned)

References

(
URL
)

Details

(Keywords: dev-doc-complete, parity-chrome, parity-safari)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.110 Safari/537.36 Steps to reproduce: Currently featured at TC39 as a Stage 3 proposal. https://github.com/tc39/proposal-regexp-unicode-property-escapes Test262 holds the tests with the `regexp-unicode-property-escapes` flag and in the `built-ins/RegExp/property-escapes/` folder. I'm updating the jstests.list to reflect all the matching test files.
The skip list is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1362169
Depends on: 1367105
Depends on: 1415827
This proposal was approved by TC39 and is now part of the ES2018 standard. It is already supported by current Chrome and by Safari TP.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Waldo, can you need-info the right person to address this issue?
status-firefox60: --- → affected
Flags: needinfo?(jwalden+bmo)
Priority: -- → P1
No longer blocks: es-2018
If Chrome and Safari already implement this, it's probable updating our irregexp import (which is being worked on now, in bug 1367105) will mean that (without too much hookup work) we'll just Get This Sort Of For Free. (There of course may be complexities involved in matching up their implementation approaches with the data we have available, for example if they implement this feature with a hard dependency on ICU -- a dependency we don't have when --without-intl-api.) Poking anba at this, although I'm not sure what exactly a needinfo here is going to do other than be mostly noise.
Flags: needinfo?(jwalden+bmo) → needinfo?(andrebargull)
(In reply to Jeff Walden [:Waldo] from comment #5) > (There of course may be complexities involved in matching up their > implementation approaches with the data we have available, for example if > they implement this feature with a hard dependency on ICU -- a dependency we > don't have when --without-intl-api.) Yes, it's going to be a hard dependency on ICU, so --without-intl-api won't get Unicode property escapes. Clearing NI because comment #5 exactly describes the current situation (requires irregexp update and then we get it basically for free).
Flags: needinfo?(andrebargull)
This was supported in Chrome 64 and now on Safari 11.1. Maybe some "parity" tags should be added here.
Blocks: es-2018
No longer blocks: es-proposals-stage-4
ONELINER testcase (from duplicate: 1500035) - this regexp should block numbers (on Chrome/Safari works, on ff not): > <input type="text" name="field" onkeydown="return /\p{L}/u.test(event.key)" >
This bug depends on Bug 1367105, which is now a P2.
status-firefox62: fix-optional → wontfix
status-firefox63: fix-optional → wontfix
status-firefox64: --- → wontfix
status-firefox65: --- → affected
Priority: P1 → P2
Type: defect → enhancement

Just wondering where this enhancement stands? I know it's a minor thing, but it would be great for creating libraries with true multi-language support for the browser.

The lack of Unicode-awareness on RegExp, even when using flag u, makes Mozilla’s own extension B!tch to Boss buggy, since it rely on \b to detect word boundaries. More generally, as someone else put it, «This makes the RegEx character classes largely useless for dealing with any real language.».

I’m posting this here since it may be considered part of the same issue, as:

(In reply to Jeff Walden [:Waldo] from comment #5)

If Chrome and Safari already implement this, it's probable updating our irregexp import […] will mean that […] we'll just Get This Sort Of For Free.

This will be landing in Firefox 78. It should be available in Nightly within a day or so. See bug 1634135.

🥳

Just to Confirm…

This means we can start writing this:

/[_$\p{ID_Start}][_$\u200c\u200d\p{ID_Continue}\u034f]*/u

Instead of this:

/[_$a-zA-Z\xaa (very long regular expression here) \u034f]*/u

… right?

@svnpenn You get no apologies from me, and the fact that you are somehow still on this thread is unacceptable.

My apologies to everyone else, it was not intended as spam, but my apologies all the same. I am still curious to the specifics, because the discussion points to \b which is much more subtle compared to \p which is implied by the op, and trying to pinpoint it in the linked threads is proving hard.

I do appreciate the moderation of my long expression, which I was not aware is problematic in this community. I would appreciate folks moderate their inbox, and accept my apologies.

(In reply to Iain Ireland [:iain] from comment #16)

This will be landing in Firefox 78. It should be available in Nightly within a day or so. See bug 1634135.

Thanks, this looks an awesome update to Firefox! I’ve updated my review on the extension to link to the bug you mention.

Fixed by the landing of bug 1634135.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.