Closed Bug 1484131 Opened 7 years ago Closed 7 years ago

Split HTMLEditor::GetFirstSelectedCellInTable() for internal use

Categories

(Core :: DOM: Editor, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla64
Tracking Status
firefox63 --- fixed
firefox64 --- fixed

People

(Reporter: masayuki, Assigned: masayuki)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 2 obsolete files)

No description provided.
HTMLEditor::GetFirstSelectedCell() is an XPCOM method, but used internally a lot. Therefore, we should create a non-virtual method for internal use. This patch creates HTMLEditor::GetFirstSelectedTableCellElement(), and it won't return NS_SUCCESS_EDITOR_ELEMENT_NOT_FOUND since nobody needs the value. It's enough to check whether the result is nullptr without error for any callers.
Attachment #9003394 - Attachment is obsolete: true
Attachment #9003395 - Attachment is obsolete: true
Priority: -- → P3
This adds automated tests for nsITableEditor.getFirstSelectedCellInTable(). However, this test crashes due to regression of bug 1484128. So, we need to uplift only this fix into the Beta.
If a cell element and its indexes in the <table> are stored in a struct, it makes the user methods easier to read. Therefore, this patch implement such struct as HTMLEditor::CellAndIndexes and make it finds first selected cell and indexes with its method. Finally, this reimplement HTMLEditor::GetFirstSelectedCellInTable() with it.
Comment on attachment 9008378 [details] Bug 1484131 - part 0: Add automated tests for nsITableEditor.getFirstSelectedCellInTable() and fixes a crash bug of it Makoto Kato [:m_kato] has approved the revision.
Attachment #9008378 - Flags: review+
Comment on attachment 9008379 [details] Bug 1484131 - part 1: Create HTMLEditor::CellAndIndexes struct to store cell element and its indexes in the <table> Makoto Kato [:m_kato] has approved the revision.
Attachment #9008379 - Flags: review+
Pushed by masayuki@d-toybox.com: https://hg.mozilla.org/integration/autoland/rev/409d6dbcca46 part 0: Add automated tests for nsITableEditor.getFirstSelectedCellInTable() and fixes a crash bug of it r=m_kato https://hg.mozilla.org/integration/autoland/rev/441e942242df part 1: Create HTMLEditor::CellAndIndexes struct to store cell element and its indexes in the <table> r=m_kato
Comment on attachment 9008378 [details] Bug 1484131 - part 0: Add automated tests for nsITableEditor.getFirstSelectedCellInTable() and fixes a crash bug of it Approval Request Comment [Feature/Bug causing the regression]: Although this is adding new automated test for legacy XPCOM API for editor, this detects and fixes a regression of bug 1484128. [User impact if declined]: Might meet the crash if user use inline-table-editing UI. [Is this code covered by automated tests?]: Yes, adding this is it. [Has the fix been verified in Nightly?]: Will be tested by this automated test (currently in autoland). [Needs manual test from QE? If yes, steps to reproduce]: No. Without the fix, this automated test hits the crash. [List of other uplifts needed for the feature/fix]: No. (The other patch for this bug is also unnecessary, it's not good patch to uplift.) [Is the change risky?]: No. [Why is the change risky/not risky?]: Just fixing the mistake to access a raw pointer. [String changes made/needed]: No.
Attachment #9008378 - Flags: approval-mozilla-beta?
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Comment on attachment 9008378 [details] Bug 1484131 - part 0: Add automated tests for nsITableEditor.getFirstSelectedCellInTable() and fixes a crash bug of it Approved for 63 beta 7, thanks.
Attachment #9008378 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
So this is a regression from bug 1484128? Or does this bug contain both a fix for the regression and a refactoring for GetFirstSelectedCellInTable? If this is the case, in the future it would be better to split things: a bug for the regression and a bug for the refactoring which is not directly fixing a regression.
Flags: needinfo?(masayuki)
(In reply to Marco Castelluccio [:marco] from comment #16) > So this is a regression from bug 1484128? Or does this bug contain both a > fix for the regression and a refactoring for GetFirstSelectedCellInTable? If > this is the case, in the future it would be better to split things: a bug > for the regression and a bug for the refactoring which is not directly > fixing a regression. This bug is for refactoring, and I found the regression when I was writing the test for safe of refactoring. Additionally, I don't have much time. Therefore, I did it as what I planned.
Flags: needinfo?(masayuki)
(In reply to Masayuki Nakano [:masayuki] (JST, +0900) (offline: 9/21-9/30) from comment #17) > (In reply to Marco Castelluccio [:marco] from comment #16) > > So this is a regression from bug 1484128? Or does this bug contain both a > > fix for the regression and a refactoring for GetFirstSelectedCellInTable? If > > this is the case, in the future it would be better to split things: a bug > > for the regression and a bug for the refactoring which is not directly > > fixing a regression. > > This bug is for refactoring, and I found the regression when I was writing > the test for safe of refactoring. Additionally, I don't have much time. > Therefore, I did it as what I planned. I understand that it takes a little more time, but there are several benefits in doing things in a self-contained way (both for tracking purposes, and for building automated tools and for analyzing Bugzilla/VCS data). It's not a rule, but it helps us, so you don't have to do it, but at least take it into account.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: