Using the per-revision bisect providing the bisect results,
Good build:55.0.2854.2 (Revision:417283).
Bad build:55.0.2857.0 (Revision:417845).

You are probably looking for a change made after 417744 (known good), but no later than 417745 (first known bad).

CHANGE-LOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/e4444ef6d703c3efd42f0961c8786aca35f574b7..a9b2754f28b5f29378a348f05ba27abbb1853f03

From the CL above, assigning the issue to the concern owner

@jaepark: Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review-Url: https://codereview.chromium.org/2328893002
Note :Able to reproduce the issue in Win 10.0,Ubuntu 14.04 & Mac 10.12.3 and Able to reproduce in latest Canary #61.0.3131.0

hnakashima@ can you take a look, I don't think it's the referenced issue but possibly something to do with our colour code for widgets?

The referenced CL is the culprit, reverting its changes fixes the issue.

Do annotations still show up in the PDF viewer if that CL is reverted?

No, other annotations stop appearing without the flag. We can't simply revert the CL.

After investigating this bug, what I found is:
1. There are 4 text boxes in this form. The first (14 0) and the fourth (17 0) (which is the bugged one) share the attribute "/T (text1)", and this links their content to be the same. The reason the string "Please enter your name in the text field ...." appears in (17 0) is that "/V" is set to that string in (14 0). For (17 0), "/V" is empty.
2. In the CPDF_AnnotList constructor, FPDF_GenerateAP is called for widgets if the AcroForm has "/NeedAppearances true" (which is the case for this file) and CPDF_InterForm::IsUpdateAPEnabled() is true.
3. FPDF_GenerateAP() causes the widget to be remade using an appearance stream which does not consider the link between (14 0) and (17 0), so (17 0) is rendered with its own "/V" field, which is empty.
4. CPDFSDK_PageView::LoadFXAnnots() draws the widgets without using FPDF_GenerateAP() on the first pass, handling the (14 0)-(17 0) link correctly. Then, when the FPDF_ANNOT flag is on, RenderPageImpl() calls the constructor of CPDF_AnnotList* with IsUpdateAPEnabled() on, and this generates an appearance stream that overwrites the previous rendering and not considering the (14 0)-(17 0).
* Potentially useless, but weird detail: the constructor of CPDF_AnnotList is called once before that, inside LoadFXAnnots() itself, but IsUpdateAPEnabled() is forced to false for this call, then restored to its previous value. Removing this forcing to false does not matter inside LoadFXAnnots(), presumably because it's drawn again before the end of LoadFXAnnots().

One thing that fixes the bug without breaking other annotations is simply removing the call to FPDF_GenerateAP from CPDF_AnnotList constructor, but that is the same as ignoring "/NeedAppearances true", which must breaking something.

Would changing FPDF_GenerateAP() to preserve the "V" key also fix the bug, without ignoring NeedAppearances?

Regressed for several milestones already - lowering priority.

FPDF_GenerateAP eventually calls GenerateWidgetAP(nWidgetType=0), which always creates a new CPDF_VariableText and does not have the old value.

I'm trying to find the mechanism that links the fields, seems like they share the same CPDF_FormField instance.

Each of the linked text fields is a different CPDFSDK_Widget instance, but both share the same CPDF_FormField and look at pField->GetValue(), then generates an appearance stream.

I don't see the point of FPDF_GenerateAP, since it just generates the same appearance stream, but incorrectly in this case.

Do you know why cpvt_generateap.cpp is needed at all?

It's actually FPDF_GenerateAP and GenerateWidgetAP that look unnecessary, not the whole cpvt_generateap.cpp.

The following revision refers to this bug:
  https://pdfium.googlesource.com/pdfium/+/84d8eb9b6fdd2afd43f5970b3544d63aa990d30e

commit 84d8eb9b6fdd2afd43f5970b3544d63aa990d30e
Author: Henrique Nakashima <hnakashima@chromium.org>
Date: Thu Jun 22 18:36:57 2017

Avoid regenerating appearance stream when already present.

Since cpdfsdk_widget.cpp already generates it, we can expect that
FPDF_GenerateAP will not be called. That implementation does not
work with widgets with a shared field.

Bug:  chromium:733528 
Change-Id: Ia436b4e8bc87ca86b67a02cf7301ac2328339128
Reviewed-on: https://pdfium-review.googlesource.com/6752
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Henrique Nakashima <hnakashima@chromium.org>

[add] https://crrev.com/84d8eb9b6fdd2afd43f5970b3544d63aa990d30e/testing/resources/pixel/bug_733528_expected.pdf.0.png
[modify] https://crrev.com/84d8eb9b6fdd2afd43f5970b3544d63aa990d30e/core/fpdfdoc/cpdf_annotlist.cpp
[add] https://crrev.com/84d8eb9b6fdd2afd43f5970b3544d63aa990d30e/testing/resources/pixel/bug_733528_expected_mac.pdf.0.png
[add] https://crrev.com/84d8eb9b6fdd2afd43f5970b3544d63aa990d30e/testing/resources/pixel/bug_733528.in