Happens in AcroForms as well. I think the DCHECK() should be simply removed, as it doesn't hold when dragging the scrollbar.

Can you mention the repro steps for non-XFA?

Sure, I'm modifying a test case to provide a concrete repro case.

The following revision refers to this bug:
  https://pdfium.googlesource.com/pdfium/+/20830920ca028f551dcdb54e5170317d61254419

commit 20830920ca028f551dcdb54e5170317d61254419
Author: Henrique Nakashima <hnakashima@chromium.org>
Date: Mon Mar 19 21:21:46 2018

Add more options to combobox_form.pdf resource.

This causes a scrollbar to appear. We need a test case that contains
an AcroForm combobox with a popup that is large enough to create a
scrollbar.

Bug: chromium:823378, chromium:820278
Change-Id: I6e93bda5b938f9f7c08ceeef7989794ea7764532
Reviewed-on: https://pdfium-review.googlesource.com/28750
Commit-Queue: Henrique Nakashima <hnakashima@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>

[modify] https://crrev.com/20830920ca028f551dcdb54e5170317d61254419/fpdfsdk/fpdfformfill_embeddertest.cpp
[modify] https://crrev.com/20830920ca028f551dcdb54e5170317d61254419/fpdfsdk/fpdfannot_embeddertest.cpp
[modify] https://crrev.com/20830920ca028f551dcdb54e5170317d61254419/testing/resources/combobox_form.pdf
[modify] https://crrev.com/20830920ca028f551dcdb54e5170317d61254419/testing/resources/combobox_form.in

In a debug build:

1. Open pdfium/testing/resources/combobox_form.pdf
2. Open the dropdown that says "Banana".
3. Scroll down and select "Zucchini".
4. Open the same dropdown again.
5. Drag the scrollbar up.

Expected: Nothing
Actual: DCHECK crash with stack:

[1:1:0319/173347.600814:FATAL:pdfium_engine.cc(1753)] Check failed: in_form_text_area_. 
#0 0x7f690e08b47d base::debug::StackTrace::StackTrace()
#1 0x7f690e089a3c base::debug::StackTrace::StackTrace()
#2 0x7f690e1115da logging::LogMessage::~LogMessage()
#3 0x55df2b06e617 chrome_pdf::PDFiumEngine::SetFormSelectedText()
#4 0x55df2b069cf0 chrome_pdf::PDFiumEngine::OnMouseMove()
#5 0x55df2b068651 chrome_pdf::PDFiumEngine::HandleEvent()
#6 0x55df2b03c767 chrome_pdf::OutOfProcessInstance::HandleInputEvent()
#7 0x55df25dd08bf pp::InputEvent_HandleEvent()

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/94f2498eab48ae4233bb694832fa398984fe9624

commit 94f2498eab48ae4233bb694832fa398984fe9624
Author: pdfium-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com <pdfium-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Date: Tue Mar 20 00:24:54 2018

Roll src/third_party/pdfium/ ef44194f4..c49f39dff (5 commits)

https://pdfium.googlesource.com/pdfium.git/+log/ef44194f4f4c..c49f39dff730

$ git log ef44194f4..c49f39dff --date=short --no-merges --format='%ad %ae %s'
2018-03-19 thestig Roll DEPS for Skia to af770026
2018-03-19 thestig Roll DEPS for catapult to 4f03e51f
2018-03-19 thestig Roll instrumented_libs to 323cf321
2018-03-19 thestig Roll v8 to 9cf8abb7
2018-03-19 hnakashima Add more options to combobox_form.pdf resource.

Created with:
  roll-dep src/third_party/pdfium
BUG=chromium:823378,chromium:820278


The AutoRoll server is located here: https://pdfium-roll.skia.org

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.


TBR=dsinclair@chromium.org

Change-Id: I05e065de1fdb1abd67dc5554c35ab4f4bccb78fe
Reviewed-on: https://chromium-review.googlesource.com/969414
Reviewed-by: pdfium-chromium-autoroll <pdfium-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Commit-Queue: pdfium-chromium-autoroll <pdfium-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#544227}
[modify] https://crrev.com/94f2498eab48ae4233bb694832fa398984fe9624/DEPS

The problem is the code that keeps |in_form_text_area_| up to do date doesn't understand when comboboxes are open. So |in_form_text_area_| gets incorrectly set to false and the DCHECK fails. Let's improve that, and keep the DCHECK.

I've been unraveling what in_form_text_area_ really is and how it is determined. It is not calculated correctly in many cases, and it's set in a crude way - whenever there is a mouse click buttons, the mouse event position is checked via FPDFPage_HasFormFieldAtPoint(). If the form field at that position is PDFiumPage::FORM_TEXT_AREA, in_form_text_area_ is set.

This leaves the following problems:
- Focusing with the keyboard using tabs does not update in_form_text_area_.
- Popups (such as the combobox options popup) are not seen by FPDFPage_HasFormFieldAtPoint(), so the flag is updated as if the combobox popup was not there. This leads to this DCHECK being very weird. It happens while moving the popup scrollbar in and out of the area where a form field is hidden under the popup.

Yes, sorry to leave you with these problems.

For tabbing with the keyboard, can you tab into a form area if you are not already in a form area?

We'll have to do more work to handle popups.

No, but you can tab from a text field into a radio button and in_form_text_area_ would still be set.

So I tried rewriting the in_form_text_area_ mechanism and instead relying on the library to tell what annotation is focused and what type of widget it is by creating the APIs:
- FPDFAnnot_GetFocusedAnnot()
- FPDFAnnot_GetWidgetType()

This worked for AcroForms, but for XFA everything is so different and I was running into all sorts of issues with the dual class structure that I gave up.

Current plan is to maintain the mechanism that's there and fix it for popups and keyboard events, even though it's brittle.

Did you ever figure out how to deal with the "Focusing with the keyboard using tabs" part? I started looking at bug 601322 and I'm using PDFiumEngine::SetInFormTextArea() calling OutOfProcessInstance::FormTextFieldFocusChange() to tell the outside world the caret has moved inside the plugin. But that does not deal with the tab key.

No, I tried the FPDFAnnot_GetFocusedAnnot idea, and when it failed I put this on hold. Will take another stab at it soon, keeping in_form_text_area_ and fixing its state.