Can you clarify what you mean, or include a screenshot? As far as I can tell, editnotices are not shown at all in the mobile version, for better or worse.

@matmarex whoops, I didn't mean mobile. I'm getting my tasks mixed up (as I've something similar to the opposite for mobile). Sorry, will update to clear it up.

Thanks for filing this, the Editing team can not prioritize at this at this time.

These are the same edit notices as the old wikitext editor, and I don't think we should be hiding any in the visual editor. If that notice is useless, then it should be removed from all editors.

@matmarex imo it's pretty useless, but maybe removing it from all editors may prove a bit more work (in terms of process)?

Would it be feasible/less work to move it to the bottom in VE (ie below the page notice)? Noting that in the old wikitext editor it's also below the page notice. That would at least make it stand out less, and make the useful notices more visible.

@JTannerWMF would editing be okay with / approve a volunteer patch for this? Either an option to disable this (from all editors), or disabling them entirely, one or the other?

In T263255#6491456, @Proc wrote:

Would it be feasible/less work to move it to the bottom in VE (ie below the page notice)? Noting that in the old wikitext editor it's also below the page notice. That would at least make it stand out less, and make the useful notices more visible.

Oh, indeed, they definitely should be in the same order in both editors. That should be an easy fix.

In T263255#6496993, @Proc wrote:

@JTannerWMF would editing be okay with / approve a volunteer patch for this? Either an option to disable this (from all editors), or disabling them entirely, one or the other?

I'd be happy to review a patch to fix the order in VisualEditor (the code is in includes/ApiVisualEditor.php, search for // Get edit notices). Although if you're not interested in this, I'll probably submit a patch myself.

I'm not sure how I feel about actually changing the edit notice. I assume it's there for a reason, and someone might be relying on it.

Although if you're not interested in this, I'll probably submit a patch myself.

@matmarex Feel free :) -- I don't think I'll get around to it at present.

I'm not sure how I feel about actually changing the edit notice. I assume it's there for a reason, and someone might be relying on it.

Well, technically speaking, the code actually considers two types of 'protection notices' separately, the semi-protection ones, and the non-semi-protection (eg full protection) ones. I'd only want to disable the semi-protection one, not the other ones.

To kinda summarise my points at the enwiki discussion (linked above): maybe the full protection ones are useful, but the semi-protection ones (i.e. editing is limited to confirmed users; 10 posts and 4 days) I don't think are. Note also that one doesn't see the notice if they're not confirmed - they can only see if it if they can edit the page, so the notice + dumping the verbose log is a bit clutter-y. The full prot ones may make sense, admittedly, because admins/privileged editors should want to be aware that it's protected because of a content dispute / other non-trivial reason, so they know to be more cautious. But the semi-prots don't really tell you anything at all - it's a very basic & common level of protection, and as such doesn't suggest the editor do anything differently at all. Some way to be able to configure this in either wmf-config, or interface admins at a wiki level, is maybe another idea?

Just my 2c.

Change 634386 had a related patch set uploaded (by ProcrastinatingReader; owner: ProcrastinatingReader):
[mediawiki/extensions/VisualEditor@master] Fix editnotice order in VisualEditor

https://gerrit.wikimedia.org/r/634386

@matmarex got around to the ordering, at least, in above patch. Could you see if it's all good, when you have time?

Thank you for the patch!

Change 634386 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Fix editnotice order in VisualEditor

https://gerrit.wikimedia.org/r/634386

@matmarex @ppelberg the patch I released was somewhat tangential to what I intended this issue to be (it's an improvement, but not a 'fix' in my eyes). I'd still like to focus on hiding these details (at least the semi-protection ones) in that message entirely, if it's something I can swing by whoever needs to sign off on this. It's really irritating for me to see that regular long log dump on every other page, most of which I just can't see a use for. On pages without an actual notice, it pops up anyway (when in its absence nothing would pop-up) and slightly throws one off. Just doesn't feel like it belongs.

Would it be better to now open a new task for this?

@matmarex ping again on the above. Alternatively, could we provide the log entry as a param to the template rather than forcefully including it via code, so a local project could collapse/trim it if they want (such as on the Pending Changes messages, see https://en.wikipedia.org/w/index.php?title=Inner_Mongolia&action=edit for example.

$protectionNotices[] = $this->msg( $noticeMsg )->parseAsBlock() . $this->getLastLogEntry( $title, 'protect' );

Okay, I'm mildly misunderstanding how the FlaggedRevs one works. Looks like it's part of /frontend/FlaggedRevsXML.php line #364 (function logDetailsToggle()).

	/**
	 * Generates (show/hide) JS toggle HTML
	 * @return string
	 */
	public static function logDetailsToggle() {
		$toggle = '<a class="fr-toggle-text" title="' .
			wfMessage( 'revreview-log-details-title' )->escaped() . '" >' .
			wfMessage( 'revreview-log-details-show' )->escaped() . '</a>';
		return '<span id="mw-fr-logtoggle" class="fr-logtoggle-details" style="display:none;">' .
			wfMessage( 'parentheses' )->rawParams( $toggle )->escaped() . '</span>';
	}

Still, that approach is much cleaner than dumping the full log. Happy with any of the above options, whichever we can get merged, so long as we can stop dumping an obscure log message to everyone?