https://github.com/tc39/proposal-regexp-lookbehind
<rdar://problem/33608833>
<rdar://problem/33183185>
it looks like devs started to use it in the wild without fallback :( steamcommunity.com - Page doesn't load after signing into Steam account · Issue #51385 · webcompat/web-bugs https://github.com/webcompat/web-bugs/issues/51385
ES2018 regex has landed in the beta channel of FF (https://bugzilla.mozilla.org/show_bug.cgi?id=1225665) due out end of June 2020. That'll mean Chrome, Edge, and FF support it but Safari still does not.
I actually used it for a neo.mjs viewmodel regex and just got a heads up that dist/prod builds no longer work in safari due to this =/ Well, at first I got a report "breaks on mobile" => did not get a JS error inside my remote debugging tools, but luckily it is reproducable on desktop. Adding this feature would be highly appreciated! Thanks, Tobias
As somebody who uses lookbehind in regex for a lot of my code, I would like to show my strong support for the resolution of this issue. Considering that all modern browsers -- save for Safari/WebKit -- support regex lookbehind, as a web developer, I find it frustrating that WebKit is the only modern browser engine which does not support this. Which, at the moment, means that I unfortunately must resort to excluding those who use Safari/WebKit browsers from accessing some of my projects, and by extension, those who use iOS/iPadOS devices too (since the use of WebKit in any web browser is unfortunately mandatory). From the report date, this issue has been around since 2017, so it is coming up to the 4-year anniversary of this issue existing, as of the time of writing. I hope that by giving my remarks on this issue, the WebKit developers take notice and implement this feature which really should have been added in some time ago. According to earlier comments, it seems that many major platforms have used regex lookbehind, which completely renders sites unusable for iOS users. Though I am not an iOS, iPadOS or macOS user myself (in part because of my views on Apple's App Store browser engine policy), I would like to see this change so that iOS/iPadOS users in particular can enjoy not just my services, but others' services too. If this issue is being worked on as we speak, I would like to therefore thank the WebKit developers in doing so.
*** Bug 226465 has been marked as a duplicate of this bug. ***
Can this be given a higher priority? All major browser except Safari support it and it has been opened for four years now... I want to use negative lookbehinds in our Ionic app which uses WKWebView. This would really reduce some complicated Regex.
Yes I agree, it would be great if be brought inline with all the other current evergreen browsers and also to the up coming spec too.
I've been tracking this one for years and I'm finally throwing a comment in here in the hope it gets bumped in priority. Due to the fact that Apple products force all browsers to use JavaScriptCore, this means that Lookbehinds still won't wont work on *most* browsers in the United States. It actually means that less Americans can use apps with Lookbehinds than can people in countries with lower GDPs (due to Apple products being more expensive)!
To anyone tracking this, I emailed the Assignee of this bug and he said "We plan on getting to it in the next couple of months." Fingers crossed
Brilliant news if that's the case! Certainly keeping my fingers crossed. It'll be great to hear an ETA for when this will be released -- I personally do not know the time it takes to implement such a feature, but I doubt it should take too long imo. That's just my naïve estimation though!
OMG, just stumbled upon this, totally surprised its not supported in Safari (which is supposed to be a "good" browser). Please implement this feature.
I really need this feature too :)
+1 to supporting an ES2018 feature in 2022. WebKit would be a good netizen to do this. Here's the relevant assertions in the ES2018 spec: https://tc39.es/ecma262/multipage/text-processing.html#sec-assertion Assertion :: ( ? <= Disjunction ) Assertion :: ( ? <! Disjunction ) For casual computing laymen like me :) https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions/Assertions#other_assertions (?<=y)x Lookbehind assertion: Matches "x" only if "x" is preceded by "y". (?<!y)x Negative lookbehind assertion: Matches "x" only if "x" is not preceded by "y". I like this optimistic summary with it's "done and dusted" attitude, with only a caveat for "older browsers" (and I think WebKit would NOT like being lumped in with IE!) https://www.regular-expressions.info/javascript.html > Lookbehind was a major omission in JavaScript’s regex syntax for the longest time. Lookbehind is part of the ECMAScript 2018 specification. It is supported by the latest versions of Chrome, Edge, and Firefox but not by older browsers such as Internet Explorer. It would be nice for it to be correctly assumed that webkit/jsc supports an ES2018 feature in 2022. Thanks! :D
Will we get this before Climate Collapse?
I've hit a website in the wild that uses lookbehind assertions and does not load on Safari. https://russiaslosses.netlify.app
(In reply to VLang from comment #11) > To anyone tracking this, I emailed the Assignee of this bug and he said "We > plan on getting to it in the next couple of months." > > Fingers crossed Is there a latest news?
We just noticed some of the code for our extension doesn't work because of this. This badly needs to be supported, it is a standard in all other browsers.
Extremely important so that our app works in both the Safari browser and with the WKWebview on iOS. Please implement asap. Thank you in advance.
just hit this bug trying to load a local instance of backstage (https://github.com/backstage/backstage) following.
I'm having the Same Problem. Any new feedback on the solution for Safira Browser?
Not really any new feedback as of yet; there's not really an easy workaround to this issue in JavaScript, either (without having to essentially write your own parser), but this does depend on what your JS code is actually doing. There hasn't been much progress on this issue for... *checks date* almost 5 years... I feel like I should send out some invitations for this issue's 5th birthday party on the 28th of July! Who's coming‽ In all seriousness, this has been a feature in Chrome since 17 October 2017, and in Firefox since 30 June 2020. Safari is still yet the only major browser to not implement this feature. WebKit, we'd love it if you would take up this issue and start working on it ─ thanks!
(In reply to James Livesey from comment #23) > Not really any new feedback as of yet; there's not really an easy workaround > to this issue in JavaScript, either (without having to essentially write > your own parser), but this does depend on what your JS code is actually > doing. > > There hasn't been much progress on this issue for... *checks date* almost 5 > years... I feel like I should send out some invitations for this issue's 5th > birthday party on the 28th of July! Who's coming‽ > > In all seriousness, this has been a feature in Chrome since 17 October 2017, > and in Firefox since 30 June 2020. Safari is still yet the only major > browser to not implement this feature. > > WebKit, we'd love it if you would take up this issue and start working on it > ─ thanks! Hell yeah! Flooding this one with comments next month. T minus 24 days!
Correction, 34 days. Same diff, 5 years.
So long. So much needed. So prevailing in usages. So unavoidable. It’s just incredibly puzzled why a modern browser still lacks this feature especially they’ve supported regexp lookahead. Sadly I’m iOS from WKWebview and Safari users have no option to choose alternatives to open pages using this. Puzzled. Will we get this implementation this year?
(In reply to Regex Guy from comment #16) > Will we get this before Climate Collapse? And this shines.
just when you thought you had the right regex
???: 5 years
this is sad
"Sad!" - Trump
Hi Michael Saboff, do you have any updates regarding the implementation of `lookbehind` and `lookahead` features?
+1 for higher priority! Fingers crossed, prayed to god, allah, buddha and hanuman! Maybe it'll help!
Can't wait for this to be fixed, so that our app is full-featured on iPhone.
Can we simply bury this bug after Queen Elizabeth's funeral?
Just realized our website was broken for weeks on Safari because of this bug! Even more frustrating is that w3school says it was implemented in Safari 12 in September 2018 (https://www.w3schools.com/js/js_2018.asp) ... but apparently not?? Now I know to never assume something works even if websites say it's ok. ALWAYS test!!! There are probably many other websites out there broken because of this oversight, given that it's from the 2018 standard. Is there any update on this?
We just realized that our website was broken on safari after 5 months of launching the website on production, and after debugging, we figure out that the problem was a lookbehind RegExp... When will you fix this bug?!
Negative lookahead seems to be bugged too. We use the following regex to search like 100 different HTML texts for different patterns, but skip HTML links. \b(?!(?:(?!<\/?[ha].*?>).)*<\/[ha].*?>)(?![^<>]*>)(PATTERN)\b(?!(?:(?!<\/?[ha].*?>).)*<\/[ha].*?>)(?![^<>]*>) Edge, Safari, Chrome are finishing in under half a second. Safari takes at least 2 minutes.
Many sites are broken. When do you plan to add this feature? We must mark last Safari browser as outdated and disable our sites for Safari because you can't implement this simple feature in 5 years. Use Blink on MacOS (iOs) if you don't want to update WebKit.
Safari is officially an outdated browser because of this
I've made an account just to comment on this specific error, which *very* far downstream is still causing problems, even outside of the Safari scope. Please fix this!
Apple forces to use WebKit for all browsers in App Store. Chrome has implemented this feature a few years ago in their Blink engine, but Chrome Mobile can't use Lookbehind, because it should use WebKit.
I had a good trawl through all the features from ECMASCRIPT 2018 to 2022 on Caniuse.com and found that very single other major browser is already 100% up to date with every JavaScript spec up to 2022 ... except for Safari. Safari has still have not implemented this from 2018, as well as one other feature from the 2019 spec. I find this unacceptable. This is going to start hurting businesses. Worse, it will mostly hurt small businesses who have less careful devs working for them, and less customers to alert them there is something wrong with the website. Why is it that non-profit organization such as Mozilla can get up to spec, but a company with over $300 billion in revenue cannot?
Apple developers are working hard on more important things - creating new emoji.
1+ Please prioritize this
It's been over 5 years, genuinely shocking.
In my opinion, it is not hyperbole to start saying this poses risk to life: I'm thinking if a health/emergency service website uses Lookbehinds. Yes, PRESUMABLY government websites will double/triple check before deploying. But assumption is the mother of all fucks ups. Even if these kinds of websites are non-functional very briefly, does Safari really want to risk a wild news story that someone died because their browser was out of date? I might not have made this rather extreme claim before, but thank you to Nalau for finding out that all other browsers are 100% up to spec with 2022. This means it is COMPLETELY SAFE TO ASSUME that specs from 5 years ago will work! How can we get this fixed? How can we escalate this issue?
*** Bug 247989 has been marked as a duplicate of this bug. ***
For some context - if one is to believe the ECMAScript compat tables at: https://kangax.github.io/compat-table/es2016plus/ this feature from ECMAScript 2018 is the only missing major feature of any version of ECMAScript up to & including ECMAScript 2021 that is not supported by Safari. Just one feature gap but ones that breaks applications assuming an ECMAScript version from a few years ago is now universally supported. Apart from closing that feature gap, I think frontend web developers would benefit from some public communication here - outlining reasons it hasn't been done yet despite Safari generally keeping up with new ECMAScript features pretty well, perhaps explaining some technical difficulties, explaining the plans of the WebKit project here.
(In reply to Sahin Deniz from comment #32) > Hi Michael Saboff, do you have any updates regarding the implementation of > `lookbehind` and `lookahead` features? Hi Michael Saboff, do you have any updates regarding the implementation of this feature?
Pull request: https://github.com/WebKit/WebKit/pull/7109
(In reply to Michael Saboff from comment #51) > Pull request: https://github.com/WebKit/WebKit/pull/7109 SO thrilled and glad to see this happening. Thanks Michael! Subscribed on Github and waiting for the PR to be merged into the base branch. Probably THE best gift for me to trust in Safari/WebKit as the main browser/web dev platform!
Committed 257823@main (46e6b3f97425): <https://commits.webkit.org/257823@main> Reviewed commits have been landed. Closing PR #7109 and removing active labels.
*** Bug 249146 has been marked as a duplicate of this bug. ***
Great job! When is it expected to show up on IOS devices, WKWebView?
It's working now in Release 161 of Safari Technology Preview, downloads are here: https://developer.apple.com/safari/resources/ Although it didn't make the the cut for the release notes!? (Celebrate those wins WebKit! :) https://developer.apple.com/safari/technology-preview/release-notes/