XSLT generate-id() returns 1, 2, 3 (counting function calls) instead of an id unique to the XML node [40877489]

Obsolete

Bug

Needs-Triage-M107

Triaged-ET

hasBisect-per-revision

RegressedIn-107

Chromium-Regression

Status Update

No update yet.

Description

be...@linguatv.com

created issue #1

Nov 9, 2022 03:26PM

**Does this work in other browsers? ** Yes - This is just a Chrome problem

Steps to reproduce the problem:

Create an XML file test.xml:

<?xml version='1.0' encoding='UTF-8' ?>

<?xml-stylesheet type="text/xsl" href="test.xsl" ?>

Create an XSLT file test.xsl

<?xml version="1.0" encoding="UTF-8"?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format">
<xsl:output method="html" omit-xml-declaration="yes" encoding="UTF-8" indent="yes"/>

<xsl:template match="test">  

	Node 'test' generate-id(): <xsl:value-of select="generate-id()" /><br/>  

	Book <xsl:value-of select="child::book[1]/@title" />: <xsl:value-of select="generate-id(child::book[1])" /><br/>  
	Book <xsl:value-of select="child::book[2]/@title" />: <xsl:value-of select="generate-id(child::book[2])" /><br/>  

</xsl:template>

</xsl:stylesheet>

Open test.xml in Chrome >= 107 will result in
Node 'test' generate-id(): id1
Book Eine kurze Geschichte von fast allem: id2
Book Die unendliche Geschichte: id3

Expected Result (here output from Firefox, similar IDs where given in Chrom <= 106)

Node 'test' generate-id(): id0xffffffffffcff480
Book Eine kurze Geschichte von fast allem: id0xffffffffffcff580
Book Die unendliche Geschichte: id0xffffffffffcff800

Now comment out line containing "Node 'test"...." in test.xsl

Result in Chrome >= 107:

Book Eine kurze Geschichte von fast allem: id1
Book Die unendliche Geschichte: id2

==> Now "id1" identifies the book, as generate-id() always returns 1 for the first call

Exprected result (again from Firefox but similar in Chrome <= 106

Book Eine kurze Geschichte von fast allem: id0xffffffffffd00580
Book Die unendliche Geschichte: id0xffffffffffd00800

==> generate-id() returned exactly the same ids for the books

Problem Description:
generate-id() is the most important function in XSLT as its output uniquely identifies a certain node node within an XML document even if the document is being transformed multiple times with different XSLT parameters.

Since Chrome 107/Edge 107 generate-id() does not return a unique id anymore but just the count of calls to it: First call returns 1, second returns 2...

This causes significant problems for all applications using XSLT, as generate-id() is the only simple way to create and pass references to a certain XML node. Even worse: There is actually no workaround for this bug!

Additional Comments:
Has been working fine for years! Affects Chrome >= 107 and Edge >=107. Still works fine in Firefox, Safari and Opera

**Chrome version: ** 107 **Channel: ** Stable

OS: Windows

Comments

be...@linguatv.com <be...@linguatv.com> #2Nov 9, 2022 03:30PM

доколе?

de...@chromium.org <de...@chromium.org> #3Nov 10, 2022 12:08PM

Assigned to ja...@chromium.org.

+1
There should be possible to open source in any installed (or minSdk for project) android API version, because compileSdk is not only one used for run the app.

Why it takes so long to release source code to SDK when the sources was already pushed to GIT?

ja...@chromium.org <ja...@chromium.org> #4Nov 10, 2022 03:36PM

Fuck this issue, always happened from android 23. Fuck this. Not friendly to developers

we...@aevum.de <we...@aevum.de> #5Nov 10, 2022 04:03PM

as a workaround you can attach outdated sources, but hope this will be fixed

https://www.reddit.com/r/androiddev/comments/6ihzli/targeting_api_26_what_do_to_about_those_missing/

ja...@chromium.org <ja...@chromium.org> #6Nov 10, 2022 05:02PM

yep, no 26 sources no funny ;(
all the bunnies gonna cry ;((

be...@linguatv.com <be...@linguatv.com> #7Nov 11, 2022 12:57AM

by the way, some temporary workaround

https://gist.github.com/J-Swift/539aaf82ffac21d5515274a24379667f but we need the official stuff for sure

we...@aevum.de <we...@aevum.de> #8Nov 11, 2022 09:07AM

be...@linguatv.com <be...@linguatv.com> #9Nov 11, 2022 11:01AM

While debugging, we consider this behavior WAI. That's because stepping through code that doesn't match SDK version of the device is not a good experience. However, we can consider fallbacks to older sources when navigating to definitions while editing your code.

be...@linguatv.com <be...@linguatv.com> #10Nov 11, 2022 11:02AM

Yes, there are possible workarounds like the one you suggest, but all of them will require a full refactoring of thousands of lines of code under the time pressure that users out there experience problems. The following up workaround is then a "Please do not use Chrome" message box. Nobody is keen on this ;)

Probably even simply adding the millis of the rendering time to the counter would mitigate the problem - maybe even blast it away entirely.

You can save our lifes!!! ;)

ja...@chromium.org <ja...@chromium.org> #11Nov 11, 2022 04:48PM

Unfortunately I don't think we can simply revert to the old behavior because the change was made to fix a security bug

https://crbug.com/chromium/1356211 and we want to keep up to date with libxml/libxslt's behavior. It also doesn't help that this is the only regression that has been filed about this change despite the behavior being released in stable chrome for almost 3 weeks already.

be...@linguatv.com <be...@linguatv.com> #12Nov 15, 2022 08:28PM

Too bad :(
But it appears to me as a cat/tail problem: client side XSLT becomes less and less popular when
- sudden changes of one implementation can lead to a sudden death of the entire application
- powerful features (and XSLT hasn't many of them) get cut away
- the inconsistencies between implementations increase

We already have the position() and the xsl:include relative path inconsistencies for over 12 years now (didn't file them... should I? Maybe all of them turn out to be expected behavior... ;).

Anyway now there is one more. Sorry for sounding frustrated.

Still hoping you find a way to return something less predictable than 1, 2, 3 for gerenate-id()....

ja...@chromium.org <ja...@chromium.org> #13Nov 18, 2022 07:44AM

Status: Won't Fix (Obsolete)

[Empty comment from Monorail migration]

ha...@google.com <ha...@google.com> #14Jan 9, 2024 07:33AM

[Empty comment from Monorail migration]

ha...@google.com <ha...@google.com> #15Jan 9, 2024 10:08AM

[Empty comment from Monorail migration]

is...@google.com <is...@google.com> #16Jan 9, 2024 10:08AM

This issue was migrated from

crbug.com/chromium/1382803?no_tracker_redirect=1

[Auto-CCs applied]
[Monorail components added to Component Tags custom field.]

IssueTracker

This issue is a part of the Chromium tracker.